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
- Re: Has the time come to get rid of the "delivering" of public headers? (continued)
Re: Has the time come to get rid of the "delivering" of public headers? · Bjoern Michaelsen
Re: Has the time come to get rid of the "delivering" of public headers? · Norbert Thiebaud
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.