bug-hurd
[Top][All Lists]
Advanced

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

Re: Using headers that install into a subdir


From: Thomas Schwinge
Subject: Re: Using headers that install into a subdir
Date: Tue, 28 Mar 2006 11:47:54 -0500
User-agent: Mutt/1.5.6+20040907i

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

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.
> 
> I just don't want to go through and figure out the best automake way to
> accommodate this just to find out that you wanted to get rid of it
> anyway.

That's the situation, taking libihash as a really simple example (since
it is self contained):

[hurd]/libihash/ihash.c
#v+
[...]
#include <stdint.h>
#include <assert.h>

#include <hurd/ihash.h>
[...]
#v-

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?

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"'.

libihash is self contained.  Now, let's have a look at libdiskfs's header
file `diskfs.h', which is apart from being used for building the library
(using the more correct (imho) `#include "diskfs.h"' which I'd also
suggest for the above `ihash.h') also installed as a public header file
in `[prefix]/include/hurd/diskfs.h'.

[hurd]/libdiskfs/diskfs.h
#v+
[...]
#include <assert.h>
#include <unistd.h>
#include <rwlock.h>
#include <hurd/ports.h>
#include <hurd/fshelp.h>
#include <hurd/iohelp.h>
#include <idvec.h>
[...]
#v-

`assert.h' and `unistd.h' are from glibc.  `rwlock.h' is from libthreads,
`ports.h' from libports, `fshelp.h' from libfshelp, `iohelp.h' from
libiohelp, and `idvec.h' from libshouldbeinlibc.

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'?

And how do we make sure that we can use the same `diskfs.h' for building
the library and for installing as a public header file--if that's what we
want?


I'll try to find a way to make this work with automake, but would
appreciate comments of any sort.


Regards,
 Thomas




reply via email to

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