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

On 21/02/12 11:59, Michael Meeks wrote:
> Hi Tor,
>
> On Tue, 2012-02-21 at 10:02 +0200, Tor Lillqvist wrote:
> > solver/INPATH/inc/MODULE/BAR.hxx as part of the "make" of MODULE, it
> > could be directly in a new top-level "inc" directory, in
> > inc/MODULE/BAR.hxx all the time. (Obviously -I$(SRC_ROOT)/inc would
> > have to be added to the compilation flags.)

that's one way of doing it, which would require all headers to be under
a new top-level directory.

not sure whether we have other options as well, e.g. how would this work:

- module/inc contains the public headers of the module
- module/source/inc contains internal headers of the module
- put top-level dir in include path

advantage is that headers stay in modules, but would require changing
all "#include <module/foo>" to <module/inc/foo> ...

>       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.

> > Now with OneGit, there shouldn't be any technical reason not do do
> > this. It would also speed up the build a little bit. Am I missing
> > something, or can I JFDI?
>
>       I'd prefer to get the MPL/LGPLv3+ on AL2 re-licensing done first, if
> possible - it's marginally more unpleasant if lots of files moved
> around; say a few months' time ?

agreed, gives us some time for bikeshedding :)

>       All the best,
>
>               Michael.