[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Traverso-devel] Build system updates, cmake
From: |
Remon |
Subject: |
Re: [Traverso-devel] Build system updates, cmake |
Date: |
Sat, 3 Nov 2007 21:56:37 +0100 |
User-agent: |
KMail/1.9.6 (enterprise 0.20070907.709405) |
Hi David,
> Awesome, very very cool.
LOL, nice that you find it cool :)
I was a little afraid you guys wouldn't like it heh.
> I've also used the waf build system http://code.google.com/p/waf/ for
> small projects and have found it quite pleasant. I write a lot of
> Python, so that is likely why I've enjoyed waf. xmms2 uses waf, but
> it's a smaller and newer project and probably doesn't have quite the
> amount of support you can find for cmake.
Ah, never heard of it. I was attracted to cmake due it has become the build
system for KDE4, so I figured if it's powerfull and easy enough for KDE4 then
it's certainly sufficient for Traverso!
A previous attempt with SCons failed, too much python or whatever it is
written in stuff :P
> Let me know when you have things we can test and I'll try it out on
> the mac. My main setup is an x86_64 debian/testing machine (where
> /bin/arch also disappeared) so I can try it there too, though if it
> works on ubuntu I'm 100% sure it'll work just fine on debian.
Hmm, strange that /bin/arch has gone!
I'm still working on it, need to add a number of defines back, and add them as
OPTION(), so they can be chosen from command line, or toggled via the gui
(with ccmake on unix systems)
> Great work man. While we're on the topic of build systems--I've found
> http://ccache.samba.org/ to be immensely helpful in speeding up my
> compile times (especially after doing a make clean). Prepending
> "ccache " to the compiler name is usually all it takes to make it
> work.
Yeah, I've used it too. However, it has it's own set of problems (using cached
files whereas it should have rebuild for example) and Traverso uses the
precompiled headers feature.
With cmake I was able to just use one precompiled header, and the whole tree
builds now in ~ 50 seconds (debug), instead of ~ 72 seconds :)
(On my system, dual core... I love it :D )
> With the new setup it could also make it simpler for specifying
> optional things to build (things that we previously would specify by
> modifying base.pri -- #defines and such).
Exactly, another reason why I started hacking on the cmake build files!
With a consistent naming, it's very easy to remember and set the correct
command line flags. (which look like
cmake . -DWANT_ALSA=ON -DWANT_JACK=OFF -DWANT_DEBUG=ON etc)
Also for packagers, who don't need to sed files (basically the base.pri file)
> I believe it's possible to
> have a simple script that sets environment variables and launches
> cmake. The cmake system can then check the env. vars for
> enabling/disabling parts of the build.
Yes, cmake can read env vars, very simple to do so!
I think I'm gonna love this system!
> Once we have things going with
> cmake I'll see if I put something like that together.
OK, would be great!
Currently I'm trying to get cpack working, but it only creates empty
tarballs :(
Hmmm, actually, for today it's enough, me starts reading a good book !
> Have a great weekend,
You 2
Remon