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

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.