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

Norbert Thiebaud nthiebaud at gmail.com
Wed Feb 22 07:23:46 PST 2012

On Tue, Feb 21, 2012 at 8:39 AM, Michael Stahl <mstahl at redhat.com> wrote:
> 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

I must say, of all the options so far, that one sound the most appealing to me.
and it can be done 'incrementally', one module at the time...

While we are at it, why not have just one public header file per
module... that would seriously simplify the header inclusion stuff.
sure the downside is that that header can be pretty big, and any
change in a module's header would trigger a rebuild of all the
dependent module..
on the other hand the include logic could be seriously simplified and
clean, and the intermodule dependecy tracking become quite light (make
wise) to a point where they can be expressed by static rules


More information about the LibreOffice mailing list