Re: moving global headers into one top-level location

Hi,

Just to clarify upfront: Getting rid of copying the header is a topic as old as
gbuild itself, fdo#61627 just did bring it up again because Michael Meeks asked
about it.

On Fri, Apr 05, 2013 at 05:54:20PM +0200, Lubos Lunak wrote:
> On Thursday 04 of April 2013, Bjoern Michaelsen wrote:
>  You might just as well write that you do not see a problem and skip the claim 
> about careful evaluation instead of this cheap jab.

Not in this particlur issue, of course there might be unknown unknowns,
learning about those would be helpful.

> > - no copying of static files to $(OUTDIR) 
> >   (might give a noticable speedup on non-symlink, slow-forking windows)
>
>  Irrelevant, make builtins avoid this.
>
> > - a lot less targets to consider (might be noticable on slow-stating
> > windows)
>
>  That is a 'might', or are there some numbers for this?

Still Windows is a lot slower. And yes, we did profile this in the early days
of gbuild at Sun and found it significant on Windows.

>  A debug build is at least 10G, a non-debug build is, what, 2.5G?, even clean 
> git checkout is 1.5G and space needed for all headers is about 30M.
>
> > - possibly unconfuses ccache for cache misses between the $(OUTDIR) and
> >   $(SRCDIR) headers
>
>  How can ccache have misses for files that use different headers? Or rather, 
> how it can not have misses there?

I havent looked into it too deeply, but at least in the old buildsystem, this
was a constant source of pain: e.g. some module had -Isolver/inc -Imodule/inc
include paths and then you would build against the second path before your
first deliver and against solver on the second.

> > - its what the Linux kernel does
>
>  Which matters why?

Michael Meeks made the valid point that its good to do something that is
expected or not totally obnoxious. Having the kernel as reference helps.


> > - no change to source files needed 
> > - cherry-picking across the change might need some simple script-foo
>
>  And that's an advantage how?

Eh, in that the other proposal needs complex script foo.

 
>  Both these ways, and the current way, make it about equally easy if one 
> really wants to do it.
>  Can we please have a clearer statement on what this would (not might) fix?

here are some more:
- Removes a huge bunch on manual bookkeeping for the Package_foo_inc copying
- Solves a lot of incremental build troubles by "header removed from source,
  but still in solver", including false positives (people pushing a broken
  state, because they still had a stale header in solver/)
- Should have some noticable impact on noop buildtimes on windows. Seeing you
  complain here[1] complaining about that, I think we share that concern.
  Of course, it doesnt magically make noop builds run in zerotime.

If you want to get an rough estimate on the impact on windows, you can -- on a
completed build -- make gb_Module_add_target ignore all targets starting with
Package_%.

Best,

Bjoern

[1] http://nabble.documentfoundation.org/rebuilt-1-cxx-linked-184-libraries-td4047929.html#a4048066