KDE/kdelibs

Bill Hoffman bill.hoffman at kitware.com
Tue Feb 7 21:35:17 CET 2006


At 03:16 PM 2/7/2006, Alexander Neundorf wrote:
>SVN commit 506872 by neundorf:
>
>-move the find_package(PCRE) from kdelibs/CMakeLists.txt to kdelibs/kjs/CMakeLists.txt
>-add a check for regex.h in kjs/CMakeLists.txt and error out if neither PCRE nor regex.h have been found
>
>build kdelibs/win independent from the rest of kdelibs/
>
>this means
>1) run cmake on kdelibs/win/
>2) make kdelibs/win
>3) install kdelibs/win
>4) run cmake in kdelibs/ -> point it to the place where kdewin32 has been installed to
>5) make kdelibs/
>6) make install
>
>Peter, can you please check that kdelibs/win/ builds and also installs this way ?
>It might still be possible that somewhere stuff from kdelibs/ is included directly. 
>Also eventually $ENV{MSSDK}/include might have to be added in kdelibs/win/
>
>ConfigureChecksWin.cmake is not used anymore, we can remove it if it works this way.
>
>Please check also that kdelibs/ configures correctly again. It is required that the include dir
>of kdewin32 is set. 
>If all the HAVE_FOO_PROTO checks still fail, please post the error messages from CMakeError.log
>
>Alex


IMO, this is still a sub optimal solution.  Why should it be so much harder to build on windows.
It should be:
cmake
make|nmake|devenv
make install

Why should one platform have to do:
cmake
make
make install
cmake 
make 
make install.

I really think it would be cleaner to provide a way to tell the build system that
you are providing some functions for a platform.  It is sort of overkill to do a try
compile for something you know is there.

-Bill



More information about the Kde-buildsystem mailing list