[Top][All Lists]

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

Re: AC_DEFINE questions (Solved)

From: Balint Joo
Subject: Re: AC_DEFINE questions (Solved)
Date: Thu, 12 Dec 2002 18:38:20 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Dear All,
        Guido and Jeff are getting into an argument here. As for me,
I opted against AC_CREATE_PREFIX_CONFIG_H on the premise that I didn't
have enough time to play with it, and didn't fully understand the documentation.

Instead I ended up solving the problem the dumb way. I didn't use the
pkh-config.h and AC_DEFINE mechanism. I created a pkg-config.h
file and used dumb substitution a la:

in the configure script:

case ${ac_foobar_condition} in
        AC_MSG_ERROR([ This shouldn't happen ])


and in the include/ file:


/* I need either FOO or BAR to be defined */


This left the package versioning defines and everything else on the command line. It is inelegant but works for me.

Thanks for the helpful suggestions/comments tho.

I have another question, dare I utter it without causing another argument? Perhaps in a separate mail.

With best wishes,

Guido Draheim wrote:

Jeff Squyres wrote:

On Thu, 12 Dec 2002, Guido Draheim wrote:

Is there a nice way to solve this problem?


it's an old problem of library makers, search the autoconf ML archive
for references. Basic point: do not install config.h, and if you don't
want to create your own, then the above macro might be
of help to you to make one up.

I'll sound off [yet again] with my usual objection:

I see no reason why there can't be a generalized header file generator in
autoconf.  i.e., one that *is* suitable for installing.  There's already
heavy machinery in autoconf to generate .h files (e.g.: not overwriting it
if it stayed the same between configure runs, switching between #define
and #undef, etc.).

For those of us who need to make publicly-installable header files, why
can't we use the same mechanisms instead of having to roll our own?

AC_CREATE_PREFIX_CONFIG_H is not an option for me.

objection refused. The autoconf at its heart is a macro package, simple as
that, no heavy machinery - the nifty functionality comes from the wealth
of macros bundled along, along with diverting to files like config.status
and config.h - so, what's wrong with taking the same mechanisms, and
what's wrong with using yet another macro to go along with those bundled?

btw, you say "I see no reason why there can't be", let me respond to that
saying "show me that it actually can". You just say "I want", other will
say "I did not need it so far, and what's existing, is sufficient". The
world of opensource is an iterative process, so may be you want to show
that it beneficial and that it can be done and that it integrates well
into the existing project.

your turn, ... and don't dare to say again something close to "I want"
and  "You are idiots if you dont' give it to me". Because that's what
I associated with your text, and I do hope that I was severly wrong that.

Dr Balint Joo                         Post Doctoral Research Fellow
Department of Physics and Astronomy
University of Edinburgh
Mayfield Road, Edinburgh EH9 3JZ
Scotland UK
Tel: 0131 650 5264 (from UK) +44-131-650-5264 (from outwith UK)
Fax: 0131 650 5212 (from UK) +44-131-650-5212 (from outwith UK)
email: address@hidden           address@hidden
WWW  :

reply via email to

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