Hi Nobert, On Sat, 23 Apr 2011 21:28:04 -0500 Norbert Thiebaud <nthiebaud@gmail.com> wrote:
This module exist only to take advantage of the ability of gbuild to build multiple modules in one single Makefile.
Great work! Just as an additional note to all: --with-max-jobs gets more important by this change as it is the only relevant limit in "tail_build". You should increment it to a sensible number of jobs. --with-num-cpus however get more irrelevant (as it is always "1" in tail_build).
looking at kohei's nice graph: http://kohei.us/wp-content/uploads/2010/07/ooo-modules.png
Maybe we can get that picture updated with tail_build replacing all the modules in it? It would make it a bit easier to read.
'scripting' is bloking the inclusion of vbahelper (alredy gbuildified) 'desktop', 'extension' seems nice target for gbuildification...
There are some weird things going on in these modules and I wonder I we should migrate them as-is or clean them up on the way. If somebody starts to work on them IMHO he should get some leeway to do not a one-to-one translation, but something that cleanly fits into gbuild.
'binfitler' will quickly get in the way... we will need to either gbuildify it, or accept the penalty of having it build last (after everything else) the former is quite a lot of work, the later is easy: just add tail_build as its dependency. Actually since binfilter is pretty big and has a lot of sub-modules it is quite likely the the over build time won't be much impacted... as it use resource quite fully on it's own.
My vote would be to build it last.
I tested things on Mac. it should be pretty platform-independent...
Worked fine here too. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen
Attachment:
signature.asc
Description: PGP signature