Re: Using headers that install into a subdir

[Roland McGrath]

> [I'm currently trying to finish the automake'ation of the Hurd's source
> tree, which Jeff began 3 1/2 years ago.]

Ha.

> On Mon, Dec 09, 2002 at 11:39:20PM -0500, Jeff Bailey wrote:
> > I've been hacking a bit on the automake version, and finally figured out
> > the whole bit where we generate stub includes in hurd/ (or other
> > subdirs) so that the mig stubs refer to the right header file.  
> > 
> > Is this hack the right long-term way to do this?  It seems ugly and
> > non-obvious.  I've been digging through other large projects like gtk
> > trying to see how they handle that, but none of them seem to have the
> > same need.

Most things that I have noticed just consolidate that header files all into
one directory in the source.  That makes it easy to have enough -I switches
to win.  We prefer to have the headers in the subdirs with their related
code, which is more natural from a source navigation perspective.

The other obvious approach is for each subdir/Makefile.am to supply
-I$(srcdir)/../libfoo for each library it uses.  

> The `ihash.h' that is supposed to be included is located in the same
> directory `ihash.c' is in.  So why don't we just include "ihash.h"
> instead?

That is a good and proper thing to do.  But it doesn't help the general
case of interlibrary (i.e. intersubdirectory) references.

> What we have to do (and are currently doing) is the following: make sure
> that we pick up the correct `ihash.h' (i.e. not
> `[prefix]/include/hurd/ihash.h', which including <hurd/ihash.h> would
> usually do) by having the build system synthesize
> `[hurd-build]/hurd/ihash.h' and add `-I[build-root]' before doing
> anything else in the `libihash' subdirectory.  That synthetic file only
> contains `#include "../libihash/ihash.h"'.

In e.g. glibc we have the same approach but not automatic; the one-line
#include files are created by hand when a new header comes along and is
used outside its subdir, and live permanently in the source tree.

> How do we--while building--get `diskfs.h' to include the correct
> `ports.h', i.e. the one from the current Hurd build tree,
> `[hurd]/libports/ports.h'?

One option here is to use #include "ports.h" in diskfs.h.  In the installed
case, that always gets the ports.h sitting next to the including diskfs.h
(i.e. /include/hurd/foo.h).  For the hurd build, it works given -I../libports.


Thanks,
Roland