Tree build system and OM2007.2
rodolphe.ortalo at free.fr
Wed Aug 1 20:19:37 CEST 2007
sorry to scratch an old itch but, shouldn't we take the opportunity of
opening OM2007.2 to think about the build system (esp. the qmake vs.
autotools thingy)? It's just that it makes me nervous for the project to
see 2 build systems available simultaneously... (Maybe I am just too
There is one thing in particular that I'd like to see in SVN: the
ability to re-conf the whole tree automatically after update and build
it without going (too much) in the individual components updates.
If possible, I'd like that starting at the "target/" subtree (or even
I don't think such a system has a chance of being adequately maintained
if the main developers do not elect a "primary" build system.
As an example, personnally, I kept on maintaining such a thing for
myself alone for a few months (for OM-2007/ only), as I really find it
useful for tracking the tree. 
Of course OE/Mokomakefile etc. are available to do that too, but I do
most of the coding attempts on the PC itself in xoo as that's much
faster natively on the PC to remake the tree or install things.
I do not want to turn this into an autotools vs qmake debate but I
wonder if we can avoid to do some comparison now that both have been
tried for a while. Mickey, especially, do you think qmake can be up to
the task for being the primary build system for everything?
 I use a recursive configure but I am sure qmake can work too (and I
am also pretty sure it will run faster! ;-). It's just I could not make
it run on the whole tree on first try in february and since then I was
too lazy to try again to learn qmake.
More information about the openmoko-devel