Es schrieb Paul Eggert:
>
> > From: Akim Demaille <[EMAIL PROTECTED]>
> > Date: 13 Mar 2002 11:23:10 +0100
> >
> > My question is merely one of interface.
> >
> > Currently
> >
> > AC_INIT
> > AC_CONFIG_HEADERS(config.h)
> > AC_CONFIG_COMMANDS(config.h, [echo Hello, world])
> > AC_OUTPUT
> >
> > is wrong (grr, it is not caught, I don't know why, but autoconf is
> > supposed to die on this).
> >
> > My question is should we make this the normal way to hook a command,
> > or should we keep this invalid, and introduce
> >
> > AC_INIT
> > AC_CONFIG_HEADERS(config.h)
> > AC_CONFIG_HOOKS(config.h, [echo Hello, world])
> > AC_OUTPUT
> >
> > or something like that?
>
> Sorry, I don't understand the question. I went back and read the
> thread, and I still don't understand the question.
>
> I did understand Russ Allbery's point. He wrote that if you need a
> config.h variant, then it should be easy enough to create the variant
> with a makefile rule that looks something like this:
>
> my_config.h: config.h
> sed 's/#define /#define MY_/; s/#undef /#undef MY_/' <config.h >$@
>
> and once you do that, you don't nee Autoconf to generate my_config.h.
>
> Guido Draheim's rejoinder
> <http://mail.gnu.org/pipermail/autoconf/2002-February/012583.html>
> doesn't make sense to me. He seems to be arguing that the makefile
> rule is too complicated. I dunno; it looks pretty simple to me.
> Maybe I'm missing something.
Did I say that? Should be "no" since the whole prefix-config.h stuff
started out as some extra makefile rule *grumble* may be we just cut
that superfluous "too" from the "complicated" characterisation. So
please accept that I did NOT want to cut-n-paste rules from file to
file to file, and if I find a bug somewhen then I have to go through
all of them and actually, the resp. sed-lines aren't that easy to
read, horrors if a few var-substitutions in there would have been
done a little different than just cut-n-paste - the bottom of it:
give the feature a simple name, and just use it. And take it, Paul,
if a feature has a name that expands to multiple lines with some
possible arg-substitutions, that's what we generally call a "macro".
back to the topic. your point is quite fine - why not let the lines
go into the makefile instead of config.status. I just wonder how to
do this - if it would be possible then it would be faaaar better
since `make` can take of the dependencies. Let's try it:
my-config.h : config.h
@PREFIX_CONFIG_H@
and let @PREFIX_CONFIG@ expands to the necessary lines to do the
conversion, and in fact it can use the normal make-autovars
like "$@" and "$<" (atleast around here it is possible). First
question: is it possible to get a SUBST that expands to
*multiple* lines. How about some of the multi-lines just broken
up with backslash-escaped newlines for readability - currently
all of the multiline rules come in from automake AFAICS but
may be I am missing something, atleast I know that gnu-make
has multline make-var substitions at hand, so it should be
possible somehow.
Secondly, how about letting the user choose a different prefix,
well the current default is the $(PACKAGE) name, but I do have
one package where the prefix differs from the package name
(zziplib -> zzip prefix). You might call that wrong scheme but
the autoconf-macro can take care of it, and give a lot of
freedom therein. - and it could contain much more knowledge of
heuristics than it does now. AFAICS, the makefile-rule above
would need a companion in the configure-script, atleast one
that sets that SUBST, e.g.
AC_PREFIX_MAKERULE(MY_PREFIX_CONFIG_H)
still there is one thing: the multiple sed-lines to do the
actual trick, they would still need to be passed around,
it changes the dicussion to let them end up in the makefile
instead of config.status - it does not get easier to be
handled in the autotools. And don't like to hear that the
autotools shall not be able to support such macro stuff,
and let the end-user be bound to cut-n-paste-n-modify.
cheers,
-- guido http://freespace.sf.net/guidod
