Re: AC_DEFINE questions (Solved)

[Balint Joo]

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
    foo)
        FOOBARDEF_SUBSTITUTION="FOO"
        ;;
    bar)
        FOOBARDEF_SUBSTITUTION="BAR"
        ;;
    *)
        AC_MSG_ERROR([ This shouldn't happen ])
        ;;
esac

AC_SUBST(FOOBARDEF_SUBSTITUTION)
...
AC_CONFIG_FILE(include/pkg-config.h)

and in the include/pkg-config.h.in file:

#ifndef INCLUDED_HEADER_FILE
#define INCLUDED_HEADER_FILE

/* I need either FOO or BAR to be defined */
#define @FOOBARDEF_SUBSTITUTION@

#endif

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,
        Balint

Guido Draheim wrote:
> Jeff Squyres wrote:
>
> > On Thu, 12 Dec 2002, Guido Draheim wrote:
> >
> >
> > > > Is there a nice way to solve this problem?
> > >
> > >
> > > AC_CREATE_PREFIX_CONFIG_H .... see http://ac-archive.sf.net
> > >
> > > 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 pkg-config.h.in, 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  : http://www.ph.ed.ac.uk/~bj
-------------------------------------------------------------------