[Top][All Lists]

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

Re: How to install "config.h"

From: Ossama Othman
Subject: Re: How to install "config.h"
Date: Mon, 30 Oct 2000 10:09:25 -0800
User-agent: Mutt/1.2.5i

Hi Hari,

On Mon, Oct 30, 2000 at 11:51:10AM -0600, Raja R Harinath wrote:
> Ossama Othman <address@hidden> writes:
> > I'm not sure that I agree with you, though I confess that I probably
> > haven't thought about this issue as much as you.  Please feel free to
> > correct me.  :-)
> But, you seem to agree ;-)

About headers that use generically named macros like PACKAGE, VERSION
and HAVE_* as automatically generated by autoconf/automake, yes.
Package specific macros, not necessarily. :-)

> The other approach, used in glib (and is explained in his book), is to
> use that information to precompute some of the results of those
> '#define's rather than use the boring #ifdef FOO_HAS_.../#endif mess
> in the other header files.  This at least pays back for installing a
> config specific header by making the rest of the headers more
> readable.

That's an interesting approach.  I'll download the glib sources and
take a look.  Thanks for the pointer!

> You can do that yourself
>   sed 's,^#define ,#define FOO_,' < config.h > foo-config.h

Quite right, though I don't see the need to change the name of the
header file if the header is placed in $pkgincludedir.  As Gary points
out, the macros will be included indirectly at some point so changing
the name of the header file won't help.

> I would be loath to changing autoconf to make installing config.h more
> convenient.  The whole philosophy of config.h is that it is used to
> improve the portablility of the particular package it's generated
> for, not as a general portability helper.  In other words, wanting to
> install config.h is itself the problem ;-)

I see your point, but it is sometimes hard to avoid installing a
config.h, particularly when autoconfiscating an application that makes
heave use of macros.  However, I do like the idea of precomputing the
results as you point out above.

Ossama Othman <address@hidden>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068  70E6 5EB7 5E71 F7A3 94A8

reply via email to

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