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.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
