moving global headers into one top-level location

[Lubos Lunak]

On Thursday 04 of April 2013, Bjoern Michaelsen wrote:
> Hi,
>
> ignited by:
>
>  https://bugs.freedesktop.org/show_bug.cgi?id=61627

 It would be nice if you could sum up the reason for all this, because the 
bugreport is rather unclear on it. As far as I understand it, the reason for 
this change seems to be that GCC's LTO has linking problems because it fails 
to merge identical definitions (which seems a GCC bug) which come from gbuild 
using several copies of our include files (which seems a gbuild bug).

> There was a discussion on moving the global headers to one central
> location.

 As if it wasn't already annoying enough to find where the header for a .cxx 
is :(.

> I am writing this mail mainly to work out the pros and cons of such a move,
> so we can carefully evaluate and prepare for impact should we go for that.
>
> First up, what are we talking about?
>
> This is the first option:
>
> Move the headers from $(SRCDIR)/$(MODULE)/inc/$(MODULE) to
> $(SRCDIR)/include/$(MODULE).
>
> What would the impact of that be?

> cons:
> - breaks traditions: old neckbeards might miss their headers in the module
> itself

 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.

> (though that would be easily mitigated with a trivial script 
> creating e.g. symlinks)

 It wouldn't, recursive search usually does not give a damn about symlinks. 
And BTW, it's not about tradition, it's about convenience.

> pros:
> - less include paths to the compiler (might give a slight speedup e.g. on
> windows)

 There is some cost associated with every -I, and actually on Windows a huge 
number of them can have a larger than just slight impact, but on the other 
hand with PCH the impact is about the same as on Linux. Barring evidence from 
somebody having an actual experience with PCH, one could argue that people 
wanting speedup on Windows would use PCH, and so this would be irrelevant.

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

> - no confusion of were a header comes from 

 LOL

> - should prevent such bugs as fdo#61627

 Which are possibly bugs on their own.

> - reduces the space needed for a build (at least on non-symlink platforms)

 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?

> - its what the Linux kernel does

 Which matters why? And if I say that KDE, GNOME and Mozilla (first one I know 
for sure, the other two look so from looking at the sources) keep headers 
together with sources and use a number of -Is, what does that mean then?

> - makes the separation between a 'public' header and a module-private one
> more explicit

 Now only if this separation currently wasn't rather confused on its own. E.g. 
Writer has a number of public and module-private headers, yet I doubt there's 
anything outside of Writer actually using any of that.

> - no change to source files needed 
> - cherry-picking across the change might need some simple script-foo

 And that's an advantage how?

> This is the second option:
>
> - $(SRCDIR)/$(MODULE)/inc contains the public headers of the module
> - $(SRCDIR)/$(MODULE)/source/inc contains internal headers of the module
> - put top-level dir in include path
>
> What would be the impact of that be?
> pros:
[been there]
> - cherry-picking across the change might need some complex script-foo
>   (not only changing locations, but also #include statements)

 And such a problem is in the pros section?

> - doesnt break tradition: headers are still in one module

> cons:
> - its not what the Linux kernel does

 Who cares.

> - keeps the separation between a 'public' header and a module-private
> header somewhat non-obvious

 Because in the first case public ones are in location A and private ones 
under <module>/source/, whereas in the second case public ones are in 
location A and private ones under <module>/source/.

> - need rewrite of all source files includes from $(MODULE)/foo to
> $(MODULE)/inc/foo
> - having -I$(SRCDIR) might introduce troubles like e.g.: 
>   - making linking against a 'private' header from another module a bit to
> easy

 Both these ways, and the current way, make it about equally easy if one 
really wants to do it.

> As you might guess, if we go for this I would clearly prefer the first
> option, but am happy to hear other opinions and input on the issue. We
> should gather all areas this might impact and go into it wellprepared.
>
> Comments welcome!

 Can we please have a clearer statement on what this would (not might) fix?

-- 
 Lubos Lunak
 l.lunak at suse.cz