[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using headers that install in other subdirs.
From: |
Alexandre Duret-Lutz |
Subject: |
Re: Using headers that install in other subdirs. |
Date: |
Mon, 16 Dec 2002 12:30:26 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
[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