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