Master branch now requires liborcus 0.5.0 or higher.

[Michael Stahl]

On 22/04/13 19:55, Bjoern Michaelsen wrote:
> 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?

the only thing the abstractions do here is get in the way.

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

that is not true,  we need to register libraries so gbuild can detect
attempted usages of non-existent libraries in partial builds.  (or
actually even non-partial builds as well currently given that many
externals are implemented using gb_*_use_libraries with no corresponding
Library).

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

clearly that problem doesn't happen often in practice.  i can't remember
a recent example.

> 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

it appears that this could be combined with PCH to be even faster.
though it's not immediately obvious to me how to implement it.
presumably there is a requirement that all files must have the same
command line parameters.