scons build files for kdegames

[Ralf Habacker]

Holger Schröder schrieb:

>Hi,
>
>at http://kdab.net/~dfaure/kdegames-scons.tar.bz2 you will find the files 
>needed to compile kdegames with scons. the 
>work is based on the SConscript files from Thomas Nagy 
>in /branches/work/kdegames-scons/v1/. 
>
Which seems not to be ported to QT4, do you have really compiled this
stuff  ( trunk/KDE/kdegames is also not ported to QT4)

>i put the SConscript files into a svn 
>checkout of kdegames trunk and added the SConstruct file and the bksys subdir 
>from kdelibs trunk. then i started adapting things for kdegames, added some 
>functions and made the SConscript files a little simpler.
>
>i would like to commit the sconscript files to kdegames trunk, and the bksys 
>subdir should go to kdegames trunk temporarily too. 
>
What does the maintainer of kdegames think about ?

>then i would like to 
>merge my changes to kdelibs bksys step by step.
>  
>
no problems here with the new functions. For the other things see below.

>this is what i changed:
>
>- make the env.subdirs() function create the dirs in the build dir on the fly, 
>also when some parent dirs have to be created on the way down to the dir, 
>too.
>  
>
Does the configure process does not build such dirs ? What is the reason
to move this generating into env.subdirs() ?

>- added a locallibs member to genobj class. this can be used to handle 
>depencencies to libs automatically in a platform-independent way:
>
>in an object you write a line:
>
>obj.locallibs = '../libkdegames/kdegames'
>
>this can the be split up into the relative path to the lib in the build dir, 
>and the platform-independent part of the lib name. then the genobj class can 
>add the dependency to the lib, when this member is not empty. by doing so, 
>the SConscript files do not have to add the env.Depends( 'xxx', 
>'#libkdegames/libkdegames.so' ) lines when they want to link against a 
>library.
>  
>
How does this feature differs from the setting a library with libpaths
and libs attribute ? Using <path>/<file> uses a filesystem related
syntax, which may be in reality not a valid path. I think this requires
some more discusssions.

>- added some new functions to install kde files:
>kdeheaders, kdeappdata, kdekcfg, kdesktopfile
>these functions take the following arguments: files, subdir
>they are used to install some files into the respective kde installation dir, 
>or a subdir thereof.`
>
seems good to me.

>the files argument can contain the * glob character, and when it does, the 
>string will be expanded to the respective files, for example '*.png' to 
>'a.png b.png c.png'. this makes installing of many similar files to the same 
>destination dir easier. the expansion is only done, if * is contained in 
>files, so no expensive reading of directories is done, when it is not used.
>  
>
Adding wildcard support looks nice to me.

>- a new kdeauto() installation function:
>it does the following tasks, if the files are there:
>  - install *.desktop file
>  - install *ui.rc file
>  - install eventsrc file
>  - installs icon files
>  - installs *.kcfg
>this makes installation of the typical kde files easier and less error prone.
>
>  
>
make sense

>- detect the version of ui files when they have the extension .ui, the same 
>way as unsermeke does it
>  
>
okay

>
>when you want to try it out, you have to extract the tarball to the kdegames 
>dir, and then do:
>
># set qt dir
>export QTDIR=/path/to/qt-4
># configure with kde dir
>scons configure prefix=/path/to/kde4
># build, and continue, when errors happen
>scons -k
># install it to where you want
>scons prefix=/some/other/path -k install
>
>  
>
Compiling a package which depends on kdelibs require mainly that the
kdelib package is installed How do you archive that the pathes in
cache/kde4.cache.py are set to the kde installation dir instead to the
kdelibs build dir ?

>then you can diff the installed stuff against a unsermake-installed version of 
>kdegames. then you will find that the installation of icons is not the same 
>as with unsermake, but the rest is alread quite similar.
>  
>
Do you know about the reasons ?

>
>please review the patches and tell me what you think about it
>  
>
I think the new functions make absolute sense and there are no problems
to check this in. What is required then is to update am2bksys.py. Are 
you working on this too ?

With the locallibs I think there are some additional discussions
required. What does Thomas say to this ?
BTW: Good work :-)

regards
Ralf