Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On Thu, Feb 23, 2012 at 10:07:21AM +0000, Michael Meeks wrote:
But for things like sw or sc, the lack of encapsulation and the need to include
75% of all the public headers in each and every compile (e.g. via
sw/inc/doc.hxx) and reparse those are a real killer.

      Ok - so, at least some better data. 

As I cant provide numbers anymore it is also just anecdotal evidence.

But this seems to suggest that the problem is not multiple include-path
sub-directories (as was suggested) but badly structured includes - which is
an orthogonal problem - right ?

Both, in a way: The huge number of includes is the root problem, but not
trivial to fix. The number of -I-switches to the compiler being performance
relevant is a symtomn of that and reducing those might improve build time, but
it is not fixing the root problem.

Fixing the root problem might involve a git hook that gives you an angry stare
for 30 seconds everytime you add more lines to a >1.5KLOC hxx than you remove
from it.

      At least, I share Tor's view that we should have some real numbers
about the cost of a given thing: multiple include paths, vs. single ones
before doing the re-licensing & then the code re-structuring ;-)

Indeed.

Best,

Bjoern

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.