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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
