Has the time come to get rid of the "delivering" of public headers?

[Michael Stahl]

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
sw/source/core/inc).

one generally learns to use ctags and grep to look up stuff anyway,
given the random 8 letter header names.