From kde-core-devel Tue Jun 14 04:26:17 2005 From: Thiago Macieira Date: Tue, 14 Jun 2005 04:26:17 +0000 To: kde-core-devel Subject: Re: Build system for KDE4 Message-Id: <200506140126.25366.thiago () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111872320029277 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1638236.eC3p4cWCWv" --nextPart1638236.eC3p4cWCWv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Alexander Neundorf wrote: >> - icon installation > >needs a custom macro (not yet written) How easy is it to add such macro? How can it be shared among KDE modules? >> - GCC visibility > >what does this mean for the buildtool ? Actually, this shouldn't be here. We need a configure test to check if gcc= =20 supports -fvisibility and, if so, enable the flag in CXXFLAGS. >> - automatic dependency resolution > >I'm not sure I understand exactly what you mean. If I say application > foo links to library libbar.so, cmake detects that libbar.so has to be > compiled before foo. That's it. Can it also do dependency resolution across different directories?=20 (make/automake can't) >> - manual hints for dependency resolution > >Not sure. Can you explain more ? It is possible to manually add > dependencies of files. Like in make: foo.cpp: fooui.ui >> - flex/bison > >needs a custom macro similar to the ones for uic, moc, kconfig_compiler > etc. flex and bison are pretty standard... They should be supported=20 out-of-the-box. >> - kdeinit support (?) > >yes With a macro, right? >> - --compile-slots, like in unsermake > >what's this ? This is an unsermake feature: it allows the user to tell the tool how many= =20 simultaneous compilations it can launch. It is different from make's -j=20 parameter in that it does not launch non-compilation jobs in parallel. It is an important feature for those building in clusters and compile=20 farms. I can launch 6 simultaneous compilations, but I don't want the=20 linker running 6 instances on my machine. Needless to say that any tool that simply generates Makefiles and lets=20 make do the job, automatically fails this point. >> - pkg-config support > >If you want to use pkg-config with cmake, you are free to do so. But it > can also be done without pkg-config. The point here is: the tool should be able to read .pc files itself,=20 without relying on running pkg-config and parsing the output. It should=20 be easy to write tests for those. >> - support rpath sanely > >cmake supports rpath. I don't know what exactly you mean with "sanely". This was one addition of mine. Currently, libtool will add to rpath everything you throw at it. That=20 means /usr on some systems, making it impossible to build and/or run KDE=20 when another KDE is already installed on prefix=3D/usr. We should be able to sanely control what goes on rpath. I know this is vague. >> - ability to link & run uninstalled binaries > >Not sure. At least it adds the rpath. As I said, I'm no linking expert. Here's something nice about libtool: when you make an application, which depends on a library you're also=20 building, you cannot run that application yet. If you did so, the dynamic=20 linker would complain that it had not found the library. libtool solves that by relinking your app with the library, and adding the= =20 path where the library is now (uninstalled) to rpath. I must add, though, that some, if not most, KDE applications won't run=20 even then. kdeinit apps, for instance, will try and load the kdeinit=20 module. Other apps may fail due to missing xmlgui configs, or even=20 missing icons. >> - easily integrated into KDevelop > >Well, does it count that cmake can generate kdevelop project files ? This is one of the "musts": the file describing the build must be machine-parseable. That rules out=20 Sconscript files directly, but it does not rule out scons. In my opinion, a simple "name =3D value" list should suffice: easy to =20 understand, and easy to parse. I would even go so far as to say: keep the Makefile.am files! >> - ability to build from svn:/trunk/KDE > >Don't know. Also one of my ideas. Suppose you went into your local checkout of /trunk/KDE, where you have=20 kdelibs, kdebase and kdepim. Instead of running: for dir in kdelibs kdebase kdepim; do cd $dir; build-command; cd .. done I want to be able to do: build-command provided the necessary files are present in /trunk/KDE or, even better,=20 automatically guessed. >> support for something like "make install DESTDIR=3D/tmp/kde-buildroot" >> to keep packagers happy > >I.e. changing the install path after compilation ? You can change the >CMAKE_INSTALL_PREFIX and then it will be installed there. This is not a "nice to have". It's a must-have feature. >It is possible to use cmake for cross-compiling. I do this every day but > in a quite special setting (http://www.neundorf.net/cmake/). I also did > some cross-compiling for Linux with cmake. But I can't tell how easy it > would be to apply this to a KDE build system. I've tried, and it's not easy. I did some Linux-to-FreeBSD cross-compiling= =20 a few years ago of the KDE code. The main reason that makes it difficult=20 is that we create tools and then run them in the same build. (mcopidl,=20 dcopidl, kconfig_compiler, etc.) If you created FreeBSD binaries, you can't run them in Linux. If the tool helped with this, it would have to detect that (say)=20 kconfig_compiler is used, and must, therefore, be compiled twice: once=20 for the native tools, and once for the cross-compilation. >Additional features of cmake: >-no other tools (no shell, no perl, no m4, no python, no automake, no > libtool, no autoconf, no autoheader, no aclocal,...) no make? >2) libtool convenience libraries >They are not really supported by cmake. I don't know if they are > actually required for anything. There are the following > solutions/workarounds: -add support for conv. libs to cmake >-write some clever macro which works good enough for us >-an extension to cmake which allows to retrieve the object files > contained in a static library and link to them We use them, but they are not really an inconvenient. The build system can simply forget about the "library" part of=20 "convenience libraries". All it has to do is add the object files that=20 compose the library into the final shared object. On Linux and GNU ld systems, libtool uses --whole-archive. On systems that= =20 don't support that, it simply adds the *.o to the link list. >cvs -d :pserver:anonymous@www.cmake.org:/cvsroot/CMake login > (respond with password cmake) Eww, cvs. That's so... March :-) j/k =2D-=20 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 4. And =E6fter se scieppend ingelogode, he wr=E1t "cenn", ac eala! se=20 rihtendgesamnung andswarode "cenn: ne w=E1t h=FA cennan 'eall'. =C1stynt." --nextPart1638236.eC3p4cWCWv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCrlxxM/XwBW70U1gRAue3AJ0RIrE2omXCm7Xblsm0QEUrOMCPuwCgpjLl 1s7su/Yd1DCSorUmWf9UvtI= =Hebv -----END PGP SIGNATURE----- --nextPart1638236.eC3p4cWCWv--