Build problems with cmake / msvc2005

[William A. Hoffman]

At 09:46 AM 3/17/2006, Alex Caudill wrote:

>You could:
>1.) use cmakesetup and modify the directories for each library location
>2.) modify the cmake cache by hand
>
>Is there some reason for treating kdewin32 as a seperate dependency? it
>seems like you could add:
>
>IF (WIN32)
>   IF (NOT KDEWIN32_FOUND)
>      add_subdirectory( win )
>
>before any of the other subdirectories (or perhaps after cmake/) and make
>this a bit more straightforward. Unless, of course, there's a good reason
>not to.

OK, this really needs to be fixed.    The problem is that kdewin32 is used
in the try compile part of cmake, as it provides system functions.  So, it
has to be built first, so that cmake can test against it.   There are some
solutions to this:

1. build kdewin32 as part of the kde build, but add a single cmake file
in the directory that tells which things it provides.   This file would have
to be updated each time a new function was added/removed from kdewin32, it
would basically contain a bunch of set(VAR true) values, which would prevent
cmake from running a try compile for this feature.  You would know very quickly
when you had this wrong as things would not buld on windows.


2.  We could build and install kdewin32 as a try compile step, then use that
version to test against.

As a cmake developer, I would strongly recommend 1.  Although you are hard
coding the contents of the library, it has some advantages.  If a function
is removed or added to the library, things will work.   Once a try compile
is done, it will not get re-run unless you delete the cache entry, so if you
remove something from kdewin32 it will be painful.   This is a real pain for
building on windows, and it adds extra complexity to the build that just
is not there on unix builds.

-Bill