GNU bug report logs - #16623
PACKAGE vs PACKAGE_TARNAME

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16623 in the body.
You can then email your comments to 16623 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: infirit <infirit <at> gmail.com>
Cc: autoconf <at> gnu.org, bug-automake <at> gnu.org
Subject: Re: PACKAGE vs PACKAGE_TARNAME
Date: Sun, 02 Feb 2014 23:21:03 +1000

[adding bug-automake]

Hi infirit,

On 02/02/14 12:25, infirit wrote:
> Hi,
>
> So for a project we wanted to make the tarball different from from the
> package name. So we updated AC_INIT and added the tarname and indeed
> now the tarball generated changes.
>
> However, we noticed that now the $PACKAGE variable is also changed to
> what we set as tarname. Which then caused files being installed in the
> wrong place as now $(pkgdatadir) changed as well.

The first argument in AC_INIT is used to set variable $PACKAGE_NAME. The 
variable $PACKAGE is set by Automake within AM_INIT_AUTOMAKE somehow 
inferred from your AC_INIT call, so this looks like a bug (or feature) 
in Automake (cc:d here). I think you can solve your problem by adding 
no-define to AM_INIT_AUTOMAKE and define variables PACKAGE and version 
yourself. Hopefully the gurus on the list have some better idea.

Cheers,
Peter

> As an example, we changed
> AC_INIT([this_is_package], [0.0.1], [http://someurl/])
>
> to
> AC_INIT([this_is_package], [0.0.1], [http://someurl/],
> [this_is_package_tarname])
>
> I tested this with a small configure.ac and empty Makefile.am. The
> example is below.
>
> --
> AC_INIT([this_is_package], [0.0.1],[http://someurl/],[this_is_package_tarname])
> AM_INIT_AUTOMAKE([1.9 foreign dist-xz no-dist-gzip])
>
> AC_OUTPUT
> AC_CONFIG_FILES([Makefile])
>
> echo ${PACKAGE}
> echo ${PACKAGE_TARNAME}
> --
>
> I put in some echo's at the end of the configure.ac and indeed the
> variables $PACKAGE and $PACKAGE_TARNAME *both* change when adding the
> tarname to AC_INIT.
>
> Is this a bug in autoconf or are we missing something?
>
> I am not subscribed so please cc me on replies.
>
> Thx
> ~infirit
>
> _______________________________________________
> Autoconf mailing list
> Autoconf <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/autoconf

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: infirit <infirit <at> gmail.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: autoconf <at> gnu.org, bug-automake <at> gnu.org
Subject: Re: PACKAGE vs PACKAGE_TARNAME
Date: Sun, 2 Feb 2014 18:56:01 +0100

On Sun, 02 Feb 2014 23:21:03 +1000
Peter Johansson <trojkan <at> gmail.com> wrote:
> [adding bug-automake]
> On 02/02/14 12:25, infirit wrote:
> > So for a project we wanted to make the tarball different from from
> > the package name. So we updated AC_INIT and added the tarname and
> > indeed now the tarball generated changes.
> >
> > However, we noticed that now the $PACKAGE variable is also changed
> > to what we set as tarname. Which then caused files being installed
> > in the wrong place as now $(pkgdatadir) changed as well.
> 
> The first argument in AC_INIT is used to set variable $PACKAGE_NAME.
> The variable $PACKAGE is set by Automake within AM_INIT_AUTOMAKE
> somehow inferred from your AC_INIT call, so this looks like a bug (or
> feature) in Automake (cc:d here). I think you can solve your problem
> by adding no-define to AM_INIT_AUTOMAKE and define variables PACKAGE
> and version yourself. Hopefully the gurus on the list have some
> better idea.

Thanks for the reply and the suggestion but it does not fix
the problem unfortunately. I tried this:

--
AC_INIT([this_is_package], [0.0.1], [http://someurl/],
[this_is_package_tarname])
AC_DEFINE([PACKAGE], ["this_is_package"], [])
AC_DEFINE([VERSION], ["0.0.1"], [])
AM_INIT_AUTOMAKE([1.9 foreign dist-xz no-dist-gzip no-define])

AC_OUTPUT
AC_CONFIG_FILES([Makefile])

echo ${PACKAGE}
echo ${PACKAGE_NAME}
echo ${PACKAGE_TARNAME}
--

But $PACKAGE is still set to "this_is_package_tarname" while I set it
to be "this_is_package" with AC_DEFINE.

thx
~infirit

> > As an example, we changed
> > AC_INIT([this_is_package], [0.0.1], [http://someurl/])
> >
> > to
> > AC_INIT([this_is_package], [0.0.1], [http://someurl/],
> > [this_is_package_tarname])
> >
> > I tested this with a small configure.ac and empty Makefile.am. The
> > example is below.

<updated example configure.ac above>

> > I put in some echo's at the end of the configure.ac and indeed the
> > variables $PACKAGE and $PACKAGE_TARNAME *both* change when adding
> > the tarname to AC_INIT.
> >
> > Is this a bug in autoconf or are we missing something?
> >
> > I am not subscribed so please cc me on replies.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: infirit <infirit <at> gmail.com>
To: bug-automake <at> gnu.org
Cc: autoconf <at> gnu.org
Subject: Re: PACKAGE vs PACKAGE_TARNAME
Date: Mon, 3 Feb 2014 00:23:32 +0100

On Sun, 2 Feb 2014 18:56:01 +0100
infirit <infirit <at> gmail.com> wrote:
> On Sun, 02 Feb 2014 23:21:03 +1000
> Peter Johansson <trojkan <at> gmail.com> wrote:
> > [adding bug-automake]
> > On 02/02/14 12:25, infirit wrote:
> > > So for a project we wanted to make the tarball different from from
> > > the package name. So we updated AC_INIT and added the tarname and
> > > indeed now the tarball generated changes.
> > >
> > > However, we noticed that now the $PACKAGE variable is also changed
> > > to what we set as tarname. Which then caused files being installed
> > > in the wrong place as now $(pkgdatadir) changed as well.
> > 
> > The first argument in AC_INIT is used to set variable $PACKAGE_NAME.
> > The variable $PACKAGE is set by Automake within AM_INIT_AUTOMAKE
> > somehow inferred from your AC_INIT call, so this looks like a bug
> > (or feature) in Automake (cc:d here). I think you can solve your
> > problem by adding no-define to AM_INIT_AUTOMAKE and define
> > variables PACKAGE and version yourself. Hopefully the gurus on the
> > list have some better idea.
> 
> Thanks for the reply and the suggestion but it does not fix
> the problem unfortunately. I tried this:
> 
> --
> AC_INIT([this_is_package], [0.0.1], [http://someurl/],
> [this_is_package_tarname])
> AC_DEFINE([PACKAGE], ["this_is_package"], [])
> AC_DEFINE([VERSION], ["0.0.1"], [])
> AM_INIT_AUTOMAKE([1.9 foreign dist-xz no-dist-gzip no-define])
> 
> AC_OUTPUT
> AC_CONFIG_FILES([Makefile])
> 
> echo ${PACKAGE}
> echo ${PACKAGE_NAME}
> echo ${PACKAGE_TARNAME}
> --
> 
> But $PACKAGE is still set to "this_is_package_tarname" while I set it
> to be "this_is_package" with AC_DEFINE.

I think I found the problem why setting tarname causes $PACKAGE to
change. In the init.m4 file AC_PACKAGE_TARNAME is explicitely used to
set $PACKAGE [1]. This is a bug and AC_PACKAGE_NAME should be used as
it is done a little bit up for a check. AC_PACKAGE_TARNAME should only
set how the tarball is named.

However I think there is a second bug in that adding no-define as an
option still sets $PACKAGE and $VERSION.

~infirit

[1] http://git.savannah.gnu.org/cgit/automake.git/tree/m4/init.m4#n72

> > > As an example, we changed
> > > AC_INIT([this_is_package], [0.0.1], [http://someurl/])
> > >
> > > to
> > > AC_INIT([this_is_package], [0.0.1], [http://someurl/],
> > > [this_is_package_tarname])
> > >
> > > I tested this with a small configure.ac and empty Makefile.am. The
> > > example is below.
> 
> <updated example configure.ac above>
> 
> > > I put in some echo's at the end of the configure.ac and indeed the
> > > variables $PACKAGE and $PACKAGE_TARNAME *both* change when adding
> > > the tarname to AC_INIT.
> > >
> > > Is this a bug in autoconf or are we missing something?
> > >
> > > I am not subscribed so please cc me on replies.

Message #14 received at 16623 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: infirit <infirit <at> gmail.com>
Cc: 16623 <at> debbugs.gnu.org
Subject: Re: bug#16623: PACKAGE vs PACKAGE_TARNAME
Date: Mon, 03 Feb 2014 11:29:44 +1000

Hi infirit,

On 02/03/2014 09:23 AM, infirit wrote:
> However I think there is a second bug in that adding no-define as an
> option still sets $PACKAGE and $VERSION.

I checked the manual again, and it says no-define has the effect that 
PACKAGE and VERSION will not be AC_DEFINEd, i.e., not included in 
config.h.in.

Sorry about the confusion.

Cheers,
Peter

-- 
Peter Johansson

Message #17 received at 16623 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: infirit <infirit <at> gmail.com>, 16623 <at> debbugs.gnu.org
Cc: autoconf <at> gnu.org
Subject: Re: bug#16623: PACKAGE vs PACKAGE_TARNAME
Date: Wed, 17 Dec 2014 23:11:53 +0100

On 02/03/2014 12:23 AM, infirit wrote:
> On Sun, 2 Feb 2014 18:56:01 +0100
> infirit <infirit <at> gmail.com> wrote:
>> On Sun, 02 Feb 2014 23:21:03 +1000
>> Peter Johansson <trojkan <at> gmail.com> wrote:
>>> [adding bug-automake]
>>> On 02/02/14 12:25, infirit wrote:
>>>> So for a project we wanted to make the tarball different from from
>>>> the package name. So we updated AC_INIT and added the tarname and
>>>> indeed now the tarball generated changes.
>>>>
>>>> However, we noticed that now the $PACKAGE variable is also changed
>>>> to what we set as tarname.
>
According to:
http://www.gnu.org/software/automake/manual/automake.html#index-PACKAGE
(and with some reading between the lines, admittedly) this is actually
WAI, and changing it now might break expectations of other packages in
a backward-incompatible fashion.

That said, we might need to improve the documentation to make this
behavior more explicit.  I'm going to attempt a patch soon.

>>>>  Which then caused files being installed
>>>> in the wrong place as now $(pkgdatadir) changed as well.
>>>
>>> The first argument in AC_INIT is used to set variable $PACKAGE_NAME.
>>>
Which could very well be a human-readable name ("My Awsome Autoconfiscated
Package"), unfit to be used in either directory names or tarball names.
That's why Autoconf mangle that in a more machine-friendly name
("my_awsome_autoconfiscated_package"), which is assigned to the
PACKAGE_TARNAME:

http://www.gnu.org/software/autoconf/manual/autoconf.html#AC_005fINIT

And since PACKAGE is expected to be used in the paths of install
directories:

  Automake extends this list with pkgdatadir, pkgincludedir, pkglibdir,
  and pkglibexecdir; these are the same as the non-'pkg' versions, but
  with '$(PACKAGE)' appended. For instance, pkglibdir is defined as
  '$(libdir)/$(PACKAGE)'.

(as stated in:
http://www.gnu.org/software/automake/manual/automake.html#index-PACKAGE_002c-directory)
it seems natural/appropriate that $PACKAGE defaults to $PACKAGE_TARNAME.

(In retrospective, PACKAGE_NAME and PACKAGE_TARNAME should have been
named differently, say, something like (respectively) 'PACKAGE_NAME_FANCY'
and 'PACKAGE_NAME_SANITIZED', or 'PACKAGE_NAME_HUMAN_READABLE' and
'PACKAGE_NAME_MACHINE_READABLE; but that particular ship has sailed long
ago).

>>> The variable $PACKAGE is set by Automake within AM_INIT_AUTOMAKE
>>> somehow inferred from your AC_INIT call, so this looks like a bug
>>> (or feature) in Automake (cc:d here).
>
The inferring of $PACKAGE_TARNAME from the first argument of AC_INIT
is actually a feature of Autoconf; Automake merely take advantage of
that by defining $PACKAGE to $PACKAGE_TARNAME (excluding those packages
which use the deprecated 1-arg AC_INIT invocation *and* the deprecated
AM_INIT_AUTOMAKE 2-args invocation, in which case $PACKAGE is the first
argument of said AM_INIT_AUTOMAKE invocation).

>>> I think you can solve your
>>> problem by adding no-define to AM_INIT_AUTOMAKE and define
>>> variables PACKAGE and version yourself.
>
As you noted yourself in a follow-up mail, that only prevents the
definition of PACKAGE in config.h, not in the configure script
nor in the Makefiles.  Again, the documentation should be clearer
about that.

>>> Hopefully the gurus on the list have some better idea.
>>
>> Thanks for the reply and the suggestion but it does not fix
>> the problem unfortunately. I tried this:
>>
>> --
>> AC_INIT([this_is_package], [0.0.1], [http://someurl/],
>> [this_is_package_tarname])
>> AC_DEFINE([PACKAGE], ["this_is_package"], [])
>> AC_DEFINE([VERSION], ["0.0.1"], [])
>> AM_INIT_AUTOMAKE([1.9 foreign dist-xz no-dist-gzip no-define])
>>
>> AC_OUTPUT
>> AC_CONFIG_FILES([Makefile])
>>
>> echo ${PACKAGE}
>> echo ${PACKAGE_NAME}
>> echo ${PACKAGE_TARNAME}
>> --
>>
>> But $PACKAGE is still set to "this_is_package_tarname" while I set it
>> to be "this_is_package" with AC_DEFINE.
>
> I think I found the problem why setting tarname causes $PACKAGE to
> change. In the init.m4 file AC_PACKAGE_TARNAME is explicitly used to
> set $PACKAGE [1]. This is a bug
>
Nope, this is WAI, for the reasons stated above.

> and AC_PACKAGE_NAME should be used
>
Nope, since $PACKAGE is meant to be used in the paths of some predefined
directory, while AC_PACKAGE_NAME is meant to be human-readable (and can
legitimately contain whitespace and special chars such as parentheses).

> as it is done a little bit up for a check. AC_PACKAGE_TARNAME should
> only set how the tarball is named.
>
> However I think there is a second bug in that adding no-define as an
> option still sets $PACKAGE and $VERSION.
>
Again, this is WAI, as need those variables to be *always* defined both
as shell and Makefile variables, for backward compatibility.

> ~infirit
>
> [1] http://git.savannah.gnu.org/cgit/automake.git/tree/m4/init.m4#n72
>
>>>> As an example, we changed
>>>> AC_INIT([this_is_package], [0.0.1], [http://someurl/])
>>>>
>>>> to
>>>> AC_INIT([this_is_package], [0.0.1], [http://someurl/],
>>>> [this_is_package_tarname])
>>>>
>>>> I tested this with a small configure.ac and empty Makefile.am. The
>>>> example is below.
>>
>> <updated example configure.ac above>
>>
>>>> I put in some echo's at the end of the configure.ac and indeed the
>>>> variables $PACKAGE and $PACKAGE_TARNAME *both* change when adding
>>>> the tarname to AC_INIT.
>>>>
>>>> Is this a bug in autoconf or are we missing something?
>>>>
>>>> I am not subscribed so please cc me on replies.
>

Patch to improve the Automake documentation coming up soon...

Thanks,
  Stefano

Message #20 received at 16623 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: Peter Johansson <trojkan <at> gmail.com>, infirit <at> gmail.com,
 16623 <at> debbugs.gnu.org
Subject: [PATCH] docs: improve description of ${PACKAGE}, ${VERSION},
 and similar variables
Date: Thu, 18 Dec 2014 00:41:50 +0100

In particular, suggesting that $PACKAGE and $VERSION should be aliases of
the $PACKAGE_TARNAME and $PACKAGE_VERSION definitions coming from AC_INIT,
and not be defined via an obsolete 2-argument invocation of AM_INIT_AUTOMAKE;
and why that is the best default, given all our historical baggage.

See discussion in http://debbugs.gnu.org/16623 for more information and
background.

* doc/automake.texi: Adjust.
* THANKS: Update.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 Will push this tomorrow evening (CET).

 THANKS            |  1 +
 doc/automake.texi | 31 +++++++++++++++++++++----------
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/THANKS b/THANKS
index 6be803e..7f84850 100644
--- a/THANKS
+++ b/THANKS
@@ -156,6 +156,7 @@ Ian Lance Taylor                ian <at> cygnus.com
 Ignacy Gawedzki                 i <at> lri.fr
 Илья Н. Голубев                 gin <at> mo.msk.ru
 Imacat                          imacat <at> mail.imacat.idv.tw
+Infirit                         infirit <at> gmail.com
 Inoue                           inoue <at> ainet.or.jp
 Jack Kelly                      jack <at> jackkelly.name
 James Amundson                  amundson <at> users.sourceforge.net
diff --git a/doc/automake.texi b/doc/automake.texi
index 736d61d..913dee4 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3914,12 +3914,15 @@ This usage is mostly obsolete because the @var{package} and @var{version}
 can be obtained from Autoconf's @code{AC_INIT} macro.  However,
 differently from what happens for @code{AC_INIT} invocations, this
 @code{AM_INIT_AUTOMAKE} invocation supports shell variables' expansions
-in the @code{PACKAGE} and @code{VERSION} arguments, and this can be
-still be useful in some selected situations.  Our hope is that future
-Autoconf versions will improve their support for package versions
-defined dynamically at configure runtime; when (and if) this happens,
-support for the two-args @code{AM_INIT_AUTOMAKE} invocation will likely
-be removed from Automake.
+in the @code{PACKAGE} and @code{VERSION} arguments (which otherwise
+defaults, respectively, to the @code{PACKAGE_TARNAME} and
+@code{PACKAGE_VERSION} defined via the @code{AC_INIT} invocation;
+@pxref{AC_INIT, , The @code{AC_INIT} macro, autoconf, The Autoconf Manual});
+and this can be still be useful in some selected situations.
+Our hope is that future Autoconf versions will improve their support
+for package versions defined dynamically at configure runtime; when
+(and if) this happens, support for the two-args @code{AM_INIT_AUTOMAKE}
+invocation will likely be removed from Automake.
 
 @anchor{Modernize AM_INIT_AUTOMAKE invocation}
 If your @file{configure.ac} has:
@@ -8381,9 +8384,13 @@ We recommend that you follow this same set of heuristics in your
 The @code{dist} rule in the generated @file{Makefile.in} can be used
 to generate a gzipped @code{tar} file and other flavors of archive for
 distribution.  The file is named based on the @code{PACKAGE} and
-@code{VERSION} variables defined by @code{AM_INIT_AUTOMAKE}
-(@pxref{Macros}); more precisely the gzipped @code{tar} file is named
-@samp{@var{package}-@var{version}.tar.gz}.
+@code{VERSION} variables automatically defined by either the
+@code{AC_INIT} invocation or by a @emph{deprecated} two-arguments
+invocation of the @code{AM_INIT_AUTOMAKE} macro (see @ref{Public Macros}
+for how these variables get their values, from either defaults or explicit
+values -- it's slightly trickier than one would expect).
+More precisely the gzipped @code{tar} file is named
+@samp{$@{PACKAGE@}-$@{VERSION@}.tar.gz}.
 @vindex GZIP_ENV
 You can use the @command{make} variable @code{GZIP_ENV} to control how gzip
 is run.  The default setting is @option{--best}.
@@ -10151,7 +10158,11 @@ brittle.
 @opindex no-define
 This option is meaningful only when passed as an argument to
 @code{AM_INIT_AUTOMAKE}.  It will prevent the @code{PACKAGE} and
-@code{VERSION} variables from being @code{AC_DEFINE}d.
+@code{VERSION} variables from being @code{AC_DEFINE}d.  But notice
+that they will remain defined as shell variables in the generated
+@code{configure}, and as make variables in the generated
+@code{Makefile}; this is deliberate, and required for backward
+compatibility.
 
 @item @option{no-dependencies}
 @cindex Option, @option{no-dependencies}
-- 
2.1.3

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.