Master branch now requires liborcus 0.5.0 or higher.

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Mon Apr 22 10:55:55 PDT 2013


Hi,

On Mon, Apr 22, 2013 at 07:06:13PM +0200, Michael Stahl wrote:
> well... all of the abstractions in gbuild don't help much for external
> libraries.  the abstractions expect the build targets to follow certain
> conventions, and in many cases enforce such conventions, but external
> libraries are not under our control and don't conform to any sort of
> conventions, especially on Windows.
> 
> so for external libraries something like gbuild actually doesn't offer
> any benefits; you need to fit the external build into the conventions
> imposed by gbuild (such as dependencies for everything and namespacing
> issues) but don't get much benefit from that because every external is
> unique in its own way.  the only reason why we build externals with
> gbuild is that we don't want to have yet another build system for them.

True, but in this case we are already not building the external project with
gbuild, essentially using the external projects native build and treating it as
a black-box -- trusting upstream to know what we are doing (and if not: fixing
it there). The remaining titbits are essentially normal packagers work, but
then they the abstractions arent that important in that case either, right?

> fortunately the de-construction of solver is already in progress :)

good riddance ;)

> > - three-layer-office (now effectly two-layer office)
> >   a lot could be simplified by ridding ourselves of that madness
> hmmm... i'm not sure if a one-layer office is really that much simpler
> than a 2-layer one... mostly the difference is just a bunch of different
> RPATH mappings on unixes.

... which is AFAIKS the only remaining fundamental reason then to have this
global register_library_foo magic at all.

> i definitely think that PCH is worth its weight given how significantly
> it speeds up MSVC builds.  without PCH we would probably be talking
> about needing 20 windows tinderboxes for gerrit, not 10.

Ya, I know, I still fear the 'only breaks on windows'-errors (because you
essentially include way more than you use etc.). But maybe that fear is just a
phantom of the pre-"remove tooltypes"-era.

And then there is the stuff like that e.g. /MP could be used having e.g. gbuild
to pipe compile commands to small buildqueue-program (prebuild a la
concat-deps) which then executes a batch at once, sparing us compiler startups,
which might or might not be faster than PCH with individual calls.

http://msdn.microsoft.com/en-us/library/vstudio/bb385193.aspx

All this messy exclusive-or stuff on Windows together with the facts like that
its unlikely that another project of our size uses PCH together with e.g.
showIncludes makes me a bit jumpy and dizzy (and one has a risk of painting
oneself in a corner with every move). ;)
 
> > Finally, let me encourage you to become/stay a 'build expert' yourself at least
> > to the point that you can judge if adding yet another feature/scenario to the
> > build system will introduce new complexity(*).
> 
> meh... we can't demand everybody become a build expert :)

I dont think having everyone tweaking on it would be a good thing even, but
enough of an idea about it to have a basic opinion on what to do and what not
is a good think IMHO.

Best,

Bjoern


More information about the LibreOffice mailing list