scons build files for kdegames
holger-kde at holgis.net
Sat Dec 3 19:03:49 CET 2005
On Saturday 03 December 2005 12:44, Ralf Habacker wrote:
> Holger Schröder schrieb:
> >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
> >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
> >- 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
> 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
> >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 :-)
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
More information about the Kde-buildsystem