Re: Using headers that install in other subdirs.

[Alexandre Duret-Lutz]

[You'd better send such questions to address@hidden, 
there are really few people reading the bug list.]

>>> "Jeff" == Jeff Bailey <address@hidden> writes:

[...]

 Jeff> a.h:
 Jeff> #include <hurd/b.h>

[...]

 Jeff> Makefile.am:
 Jeff> hurdincludedir = ${includdir}/hurd
 Jeff> hurdinclude_HEADERS = a.h b.h
 Jeff> bin_PROGRAMS = main

 Jeff> The problem here is that a.h then finds the installed b.h, not the local
 Jeff> b.h (or fails if there isn't one installed).  The reason we need to do
 Jeff> it this way is that "a.h" is a generated RPC stub that gets installed.

 Jeff> I can't find any information on the Right Way to solve this - and I
 Jeff> can't seem to find other projects that need to chain header files like
 Jeff> this and where the header files aren't located directly in
 Jeff> compiler-searched directories. 

Well, if `a.h' includes `hurd/b.h', `b.h' must lie in a `hurd/'
directory; I can't see any way around.  That issue exists
whether you use Automake or not.  IMO the simplest solution is
to shape your source tree the way it will be installed.

That means either using a global hurd/ directory (AFAICT that's
what they do in Linux for include/linux/, or in the glibc for
include/), or many hurd/ directories local to each module.

Another idea is to add a `hurd -> .' symlink in each module.
This way <hurd/b.h> and "b.h" can both be used.

 Jeff> Currently the Hurd sources set a bunch of variables and
 Jeff> then generate stub header files in $(top_builddir)/hurd
 Jeff> based on those, but it seems like there must be a better
 Jeff> way.

This doesn't look like a bad idea.  Has this caused any issue?
(Usually people are leery of changing something that works.)
-- 
Alexandre Duret-Lutz