Hi Thorsten,
Björns approach is the first one in the last 10 years I can see has
potential, to simplify the build, to improve scalability, to improve
dependencies, to improve build performance, to align our makefiles, to
reduce code.
A build system, in particular one based on (GNU) make, is a query
system. I as a user ask it for a target / file, the system figures out
how to best provide it. If the system is good, it utilizes my resources
properly.
As outlined in a blog posting a while ago, we shouldn't need to write
any makefiles anyway, agreed. This is some way to go.
Compiler / Linker flags for a particular source file should certainly be
located in or close to the source file. Same holds true for linking
libraries. If one follows some conventions, a build system can easily
derive what needs to be linked. Ideally the build system would even be
something I call "stable", after a build (cold or hot) the output
directory would never hold a file not needed for the target, directly or
indirectly.
But whatever we can think of, it needs to be implemented iteratively, I
am sure you agree. Björns prototype really is a good step forward, all
the other nice things can be implemented on top.
So let's go
Kay
Thorsten Behrens wrote:
Hi Mathias,
most of the points you've raised I already replied to in my followup
to Bjoern (including my ideal msword lib makefile) -
Mathias Bauer wrote:
build.pl uses module dependencies, not target dependencies, so it has an
inherent susceptibility to bottlenecks. Basically all of our c++ sources
could be built in parallel (as they don't depend on each other), but
with build.pl we always have to wait until header files are "delivered"
or created. And because the dependency granularity level is the "module"
(not a real target like e.g. a library), we can't use as much
parallelization as possible. This becomes even more painful if you don't
build the whole office, but only some parts of it, e.g. in a split build
or if you rebuild several "modules".
Ah interesting - so we're then moving away from the solver concept?
No, really, there's nothing nailed until now. If you or anybody else
knew a better way and(!) offered help and cooperation, there's nothing
that would hold us back from doing it differently.
I find this "and(!)" slightly worrying - not that I would not lend a
helping hand; but why are you refusing advise from people just
because they may not have time helping you with coding?
That's why he went for bjam ...
Can you explain if bjam is able to fulfill the requirements Björn and I
have mentioned and what else it can do better than GNU make? Or can you
at least explain why you perhaps prefer it?
I didn't say I'd prefer it. I was just pointing to that project, and
the experiences. Maybe it would help the discussion if more of the
internal findings you mentioned would be public - come to think of
it, maybe it would have been nice to have the whole discussion that
led to this prototype public, in the first place ... ;)
Cheers,
-- Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
