Re: Re: Building OpenOffice.org with GNU make

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