[Top][All Lists]

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

Re: Making variably-named .in files work with config.status

From: Nick Bowler
Subject: Re: Making variably-named .in files work with config.status
Date: Mon, 24 Dec 2012 10:16:01 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On 2012-12-23 21:36 +0000, Reuben Thomas wrote:
> In my configure.ac, I have:
> AC_SUBST(PACKAGE) # so that automake can generate dependencies for 
> ${PACKAGE}*.rockspec

While this is not related to your problem, note that your macro
arguments are underquoted.  Since the arguments are (presumably) not
meant to be subject to macro expansion, they should have one level of
quotation, as in:


The Autoconf manual includes a whole section on the gory details of M4

Furthermore, AC_SUBST([PACKAGE]) is not required (but should not be
harmful) as Automake does this automatically.

> This works in getting the requisite dependency generated in Makefile.in:
> ${PACKAGE}-git-1.rockspec: $(top_builddir)/config.status
> $(srcdir)/${PACKAGE}-git-1.rockspec.in
>     cd $(top_builddir) && $(SHELL) ./config.status $@
> But when I actually try to use the rule, it fails:
> $ make zee-git-1.rockspec
> cd . && /bin/bash ./config.status zee-git-1.rockspec
> config.status: error: invalid argument: `zee-git-1.rockspec'
> make: *** [zee-git-1.rockspec] Error 1
> As far as I can tell, this is because config.status doesn't get passed a
> value for PACKAGE.

I suspect (without testing) that config.status is actually looking
to generate a file called, literally, ${PACKAGE}.rockspec from
${PACKAGE}.rockspec.in.  This is wrong, because what you wanted was
for ${PACKAGE} to be replaced with the package name.

> AC_ARG_VAR doesn't seem to be relevant here, and I'm out of other ideas
> after searching online and reading the autoconf manual. What should I be
> doing here?

While I don't know if you can successfully use shell variables in
AC_CONFIG_FILES, there is another possibility in your case.
Autoconf defines the macro:


which expands to the package name at M4 time.  This should be usable in
the argument to AC_CONFIG_FILES, with something like (untested):


Note the (lack of) quoting around the call to m4_defn: this is because
m4_defn produces an appropriately quoted string and we actually want
that macro to be expanded before passing the result to AC_CONFIG_FILES.
But the rest of the argument is quoted because that part should not be
subject to macro expansion.

Hope that helps,
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

reply via email to

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