bksys / scons (Re: win32 port)

[Alexander Neundorf]

Hi,

since many here seem to consider creating buildsystems a very complicated 
task, I have to reply. I managed to do it with cmake, it wasn't really hard, 
and I'm quite sure there would be no major problems using the same under 
windows.
Many things you are discussing here are already implemented by cmake, and: 
*the cmake guys want cmake to become the buildsystem for KDE4*.

On Tuesday 10 January 2006 16:37, Holger Schröder wrote:
...
> we want the build system to be "single-pass", that means: when i add a
> source file to any SConscript file, a call to scons should do everything
> that is necessary: rebuild the target, when the target is a library, relink
> the programs, that link against it, if needed. no more create_makefile, and
> no more strange errors, because people forget to call it.
>
> we want the syntax of the normal Makefile.am replacements (now SConscript
> files) to be platform-independent and simple. for example (from
> kdelibs/kabc/Makefile.am) :
>  libkabc_la_LIBADD = vcardparser/libvcards.la $(LIB_KIO) \
>                     $(top_builddir)/kresources/libkresources.la
>
> in these two lines the beginning "lib"-prefix is redundant, the
> "$(top_builddir)" is redundant, and the ".la"/"_la_" is redundant, and i am
> not sure, if these lines tell unsermake, that libkresources.la should be
> built before libkabc.

With cmake this would look like:

ADD_LIBRARY(kabc SHARED ${kabcSources} )
TARGET_LINK_LIBRARIES(kabc vcards kresources kio)

With ADD_LIBRARY cmake knows implicitely which prefixes and suffixes to use on 
which platform (e.g. on linux libkabc.so). 
TARGET_LINK_LIBRARIES tells cmake to link the target "kabc" (which is a 
library) to the libraries libvcards.so, libkresources.so and libkio.so (and 
vcards.dll, kresources.dll and kio.dll under Windows).
If this is all inside kdelibs/, cmake knows that vcards is one of the targets 
and so will build it before kabc, same for kresources and kio.

> we have to create replacements for any bash-snippets in Makefile.am´s, when
> it should become platform-independent. it is for example used to copy some
> files to a installation dir, to do globbing for files, etc. this will never
> work under windows, and if it would, it would be a maintenance nightmare. (
> think about path separators, etc. ).

cmake does this in a portable way, scons/python too.

...
> so the whole thing is quite complex, and we have to think about a lot of
> things. and i think we are quite successful at implementing a new build
> system when working on a moving target (kdelibs trunk). from the list above
> quite some things, that do already work under scons would have to be
> reimplemented, when we would want to try cmake to build kde under
> windows/mac os, for example detecting libraries under windows, or replacing
> embedded bash-scripts by platform-independent python scripts.

Of course they would have to be implemented in cmake-style, where's there 
problem ?

> so i think we are already quite far with scons/bksys:
> we can build some subset of kdelibs, without need for any changes in the
> source files. we do not interfere with the unsermake system, so we do not
> delay anybody, who wants to hack on kde and who does not want to fiddle
> around with the build system.

Honestly, I managed to do the same with a very limited amount of time with 
cmake without help from anybody for KDE3, and I knew basically nothing about 
the KDE build system before this.

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