Re: Master branch now requires liborcus 0.5.0 or higher.

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.