Master branch now requires liborcus 0.5.0 or higher.

[Michael Stahl]

On 21/04/13 12:33, Bjoern Michaelsen wrote:
> On Tue, Apr 16, 2013 at 12:32:13PM -0400, Kohei Yoshida wrote:
> 
>> Having said that, if I were to point out one major concern with the current
>> build system is that we are creating so many layers of abstractions,
>> indirections just to make the system more "elegant" that, it's becoming
>> increasing hard for non-build system experts to do anything non-trivial.
>> So, for a non-build system expert such as myself, the choices are either 1)
>> don't do anything non-trivial, such as integrating an external library into
>> the build, or 2) become a build expert yourself.

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.

> I think there are two thing to discuss here: One is the common assumption that
> building LibreOffice on multiple platforms is trivial, and the complexity is
> there only for some misguided "elegance". Its not. Its an inherently complex
> problem. And I dont think having some layers of abstraction is a problem per
> se. A lot of the mindnumbling complexity of gbuild is because:
> 
> - it had to stay compatible with the dmake/solver concept
>   (we can rid ourselves of that now it is completely gone, modulo scp2 madness)

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

> - 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.

> - platform-specific optimizations that are not completely transparent
>   (this esp. is an issue for windows)
> 
> We killed the first. I hope we can kill the second someday. The third is the
> reason for my reluctance for having support in the build system for bazillion
> build scenarios in gbuild (like LLVM, mingw, Android, ccache on Windows, PCH on
> Windows) -- all of which add complexity to the build system and many having
> only a very small group supporting that functionality introducing fragility and
> frustration. Thats warranted when the platform is of strategic importance, but
> e.g. even with the build time improvements PCH give, I am still unsure if its
> worth the complexity and fragility it introduces.

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.

> 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 :)