> [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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
