Has the time come to get rid of the "delivering" of public headers?
mstahl at redhat.com
Wed Feb 22 07:01:06 PST 2012
On 22/02/12 15:09, Lubos Lunak wrote:
> On Tuesday 21 of February 2012, Michael Stahl wrote:
>>> I wonder how bad the alternative of adding -I$S/svx/inc -I$S/vcl/inc
>>> etc. etc. is for command-line length ?
>> would need to try that out on Windows, but my guess is that even if it
>> doesn't blow out command line length limits (which could be worked
>> around with a response file) it'll make the Windows build a lot slower
>> because compiler has to try out all include paths (well statistically
>> half of them but that is bad enough) for every included files, and those
>> file accesses take forever on Windows.
> Could not the windows build be helped by having only one location for include
> files where a script would at the beginning of the build create for each .hxx
> file a small wrapper with the same name only doing #include of the real one,
> with the right path to it?
that sounds like a horrible hack (and it would still be necessary to
open 2 files instead of 1 so it would still be slower).
another simple alternative might be to have a single directory that
contains symlinks to all module inc directories:
inc/$MODULE -> $SRC_ROOT/$MODULE/inc/$MODULE
but i have doubts that that would actually work on windows, is there any
kind of link that MSVC will follow?
> And, since I'm already asking, is the Windows performance the reason include
> files are scattered this way? E.g. in sw/ I find this actually rather
> annoying, some .hxx files are in inc/, some next to .cxx sources, Writer
> AFAIK does not really export anything anyway, and I always have to jump
> around just to find the right header file :(.
in sw the include files are distributed to ensure that e.g. core
implementation details are not available to UI code (though there is
probably still a lot of stuff in sw/inc that really should be in
one generally learns to use ctags and grep to look up stuff anyway,
given the random 8 letter header names.
More information about the LibreOffice