[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

header files

From: Neal H. Walfield
Subject: header files
Date: 19 Aug 2002 17:49:16 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2

I am currently in the process of porting the Hurd to the L4
microkernel.  At the moment, the Hurd uses custom makefiles which, to
be nice, are a jungle.  Rather than try to extend them to support a
new idl compiler and microkernel dependent files, I decided to try to
use automake and autoconf.

One of the main goals of this port is to be able to build the Hurd for
both GNU Mach or L4 on any supported architecture.  My current
situation is as follows: I will have between twenty and thirty top
level subdirectories which contain either an implementation for a
library or a program.  The system independent code lives in the root
of the subdirectory.  Any system or architecture specific code hangs
off of a the subdirectory's sysdeps directory.  For instance, a
program foo might have the following directory layout:

hurd/foo/ will contain a list of the files (without
directories) and a VPATH to find the appropriate source files.  For

  VPATH += $(srcdir)/sysdeps/@MICROKERNEL@/@ARCH@/ \
           $(srcdir)/sysdeps/@MICROKERNEL@/ \
           $(srcdir)/sysdeps/@ARCH@/ \
           $(srcdir)/sysdeps/generic/@ARCH@/ \
           $(srcdir)/sysdeps/generic/ \
The same technique can be used with header files (substituting
AM_CPPFLAGS for VPATH, of course).  This works well and does not
violate the abstraction--foo can know its own layout.  A problem
arises however, when foo needs to use header files from other
directories.  This is in fact quite common.  Consider: foo would like
to use the library libbar.  libbar has a sysdeps layout similar to
foo's.  It has a header file in the root of its subdirectory called
bar.h. bar.h includes a file <bits/bar.h>.  Implementations of
bits/bar.h can be found in both hurd/libbar/sysdeps/l4/bits/bar.h and
hurd/libbar/sysdeps/mach/bar.h.  In order for foo to use the right
one, it must have internal knowledge of bar's directory layout.  This
is bad, however, a possible work around in the single library / single
program case.  It becomes unreasonable when scaled to tens of
libraries used by tens of programs.

What I would like to happen is have make first run a "build-header"
target in each subdirectory which causes the header files to be
installed in $(top_builddir)/include (optimally via symbolic links).
Then during the second pass (when everything is actually built),
CPPFLAGS would be set to contain `-I$(top_builddir)/include'.  I
currently only see one real problem with this proposed solution: I
have no idea how to implement it using automake.  Ideas, suggestions,
criticisms and work arounds are all welcome.  Please remember to cc me
in replies as I am not subscribed to this list.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]