scons build files for kdegames

[Holger Schröder]

On Saturday 03 December 2005 12:44, Ralf Habacker wrote:
> 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)
>
well, i tried to compile it, and under linux i could even start kmines. for 
some reason, the processes seem to bring the cpu to 100 % load, something in 
the kmines process or dcopserver i suppose, and kmines still has some redraw 
errors.

> >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 ?
>
i don´t know. is there a kdegames-maintainer ?

> >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() ?
>
well, the part in SConstruct, that creates the pathes did only run when you 
did scons configure iirc, and it only created the topsubdirs, i.e. it could 
create build/dir1, but not build/dir2/dir3. so i made a new function makedir, 
which can create new pathes, not only single subdirs. the other point is, 
that there was no way to call env.subdirs() from any SConscript file in a 
subdir, as then the build directories would not be created.

so concluding i would say, that the subdirs function is the right place to 
create the subdirs, when they do not yet exist on the fly. in the kdelibs 
SConstruct file, the subdirs are also created directly before calling 
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.
>
well, every SConscript file is in a subdir, and from there you can say i want 
to link to the kdegames lib in ../libkdegames. when executing this object, 
one could automatically add the dependency: "i want this object to be built 
after libkdegames". i have not fully understood the Aliases function, but i 
think it should be possible to do the following:

when a shared or static lib is built, create the lib, say libkdegames.so.x.y.z 
or *.dylib or *.dll. and then add an alias for that: kdegames.library. it is 
only a platform-independent name for the lib. so we have a fixed reference 
point to the lib.

then when a program links to that lib, we know the relative path to the lib, 
and we can then when execute()ing that program say "i depend 
on ../libkdegames/kdegames.library" and it would work for linux, mac os and 
windows, and we do not have to add the dep in every SConscript file.


> >- 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 ?
>
i did not check for that yet. it simply uses prefix as a reference to kdedir. 
i only added some stuff in the detect_kde.py to include the include path and 
the lib and the bin path into the env. so this is no clean solution yet. i 
wanted to start from the SConscript file contents and wanted to make them as 
simple as possible, the other steps would be for later.

> >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 ?
>
i have not looked into icon handling jet. the function checks for some png 
files in a dir, then mangles the filenames and installs the found files into 
some dirs in the install path. i think the implementation is not current any 
more, but the calls to that function from the SConscript files are fine.

> >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 ?
>
not yet. my next task is to try to compile kdelibs under msvc.net and then 
see, which things must be changed to get it to work. christian told me, that 
you were working on some dep file support. i do not understand what this 
does. does it only create empty files ? what are they good for ?

yesterday i tried to automatically add implicit dependencies to libs, for 
example when you link a program with msvc against kparts, ti should 
automatically add kdecore and kio. i am not finished with this, but i have a 
"proof of concept": i had to create an own builder for SharedLibrary and 
Program. they do the same things as the default actions of scons, but before 
that they scan over the LIBS and add kdecore, when they find kparts.

the problem is, that i want to build up that information from the kdeobj, that 
builds libkparts, but i have not yet found a way to give any information from 
that kdeobj instance to the builders. so i will try to save it into some 
file, and then read it when building a program or shared lib.

> With the locallibs I think there are some additional discussions
> required. What does Thomas say to this ?
> BTW: Good work :-)
>
> regards
> Ralf
>
>
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem