Hi Hari,
On Mon, Oct 30, 2000 at 11:51:10AM -0600, Raja R Harinath wrote:
> Ossama Othman <[EMAIL PROTECTED]> 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
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
