bksys / scons (Re: win32 port)

[Alexander Neundorf]

Hi, 

On Monday 09 January 2006 19:38, David Faure wrote:
> On Monday 09 January 2006 18:33, Jaison Lee wrote:
> > scons/bksys has been in development for months and yet it seems to be
> > months away at best from even being serviceable. Perhaps it's time to
> > cut our losses and run.
>
> Honestly, that's my feeling too. As it is right now, we're stuck: no way
> to work on the configuration since it's not modular, and no way to compile
> kdelibs since kconfig_compiler can't be run.
>
> > On 1/9/06, Alexander Neundorf <neundorf at kde.org> wrote:
> > > -they have a fully working configure-like framework, dead-easy to use
>
> Is it modular, i.e. does it collect the tests from various subdirs of the
> source tree?

I don't understand exactly what you mean by "modular", so I'll just explain 
how it works.

A test is written like this (e.g. for a header):

#include the file which contains the check_include_files function
INCLUDE(CheckIncludeFiles)
#the tests
CHECK_INCLUDE_FILES( unistd.h HAVE_UNISTD_H)
CHECK_INCLUDE_FILES( string.h HAVE_STRING_H)
#write the results into a config header
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/config.h.cmake 
${CMAKE_CURRENT_BINARY_DIR}/config.h)

These commands can be written in any CMakeLists.txt in any directory. When 
cmake runs, they will be executed, and there is a cache. configure_file() can 
"configure" any files. So e.g. if kio_man needs to check for UNISTD_H, this 
can be done in kioslave/man/CMakeLists.txt, and typically a config.h could be 
created in kioslave/man/config.h. If the result is intended to go into 
kdebase/config.h, then the test should typically be in kdebase/CMakeLists.txt 
(or a file included in CMakeLists.txt). Probably something could be done to 
"collect" cmake test files from a complete directory tree and execute them 
all from the toplevel. Maybe FILE(GLOB_RECURSE kde_test_files 
"ConfigureTests.cmake") or something like that (which would store a list of 
all files named "ConfigureTests.cmake" in the variable kde_test_files, which 
could be iterated and each of them included and thereby executed). Not sure 
where this would have advantages.
I chose the name config.h.cmake so that it doesn't conflict with config.h.in. 
Other than that it can be freele chosen.
config.h.in can look like this:

#ifndef CONFIG_H
#define CONFIG_H
#cmakedefine HAVE_UNISTD_H
#cmakedefine01 HAVE_STRING_H

#define SOMETHING_ELSE ${A_CMAKE_VARIABLE}
#define ANOTHER_THING @ANOTHER_CMAKE_VARIABLE@

#endif

When cmake is run, a config.h will be created.
#cmakedefine will turn into a #define/#undef HAVE_UNISTD_H
#cmakedefine01 will turn into a #define HAVE_STRING_H 0/1
Both ${A_CMAKE_VARIABLE} and @ANOTHER_CMAKE_VARIABLE@ will be replaced with 
the contents of these variables in cmake.

> > > -cmake can generate Makefiles and *projects* for KDevelop3, MSVC 6,7,
> > > XCode
>
> Generating Makefiles is probably the ugly thing about it.
> You don't mention performance; how fast does "make" go on an already built
> tree, compared to unsermake or bksys?

Don't know, didn't compare. Version 2.2.0 to 2.2.4 had a quite big performance 
problem with dependency scanning, this is fixed in cvs and will be fixed with 
the next release. Now only source files which have changed since the last run 
are scanned again.

> > > -I added cmake files to compile software for KDE3 some days ago to svn,
> > > including sample CMakeLists.txt (generated by am2cmake):
> > > http://websvn.kde.org/trunk/KDE/kdesdk/cmake/kde3/
>
> Some abstraction work is needed, of course, e.g.
> INSTALL_FILES( /share/apps/kconf_update FILES kcalcrc.upd )
> shouldn't hardcode /share/apps, but should use some variable for it
> (kde_datadir).
>
> But other than that, well, we'll get used to the syntax I guess :)

This would be no problem (setting KDE_DATA_DIR in FindKDE3.cmake and using 
this instead). But aren't the paths below ${INSTALL_PREFIX} basically fixed ?

> > > -not sure: relinking during installation
>
> That would be awfully slow. Can you look into that? Does it relink during
> installation, or relink when launching a local binary (like libtool), or
> does it use LD_LIBRARY_PATH (which breaks with rpath, as Thiago said).

AFAIK (I'm no linking expert) it doesn't relink during installation. The rpath 
is set to the library where it was compiled. This can be disabled. I was able 
to compile kdelibs and run the things which had been built during this run 
from their compile directory.
For these issues I would suggest that either somebody who knows more about 
linking than me joins the cmake list or I'll ask on the cmake list whether 
one of their developers can join this list.

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net