GNU bug report logs -
#16623
PACKAGE vs PACKAGE_TARNAME
Previous Next
Reported by: Peter Johansson <trojkan <at> gmail.com>
Date: Sun, 2 Feb 2014 13:22:02 UTC
Severity: normal
Tags: patch
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
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.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#16623
; Package
automake
.
(Sun, 02 Feb 2014 13:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Johansson <trojkan <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Sun, 02 Feb 2014 13:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[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
Information forwarded
to
bug-automake <at> gnu.org
:
bug#16623
; Package
automake
.
(Sun, 02 Feb 2014 19:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#16623
; Package
automake
.
(Sun, 02 Feb 2014 23:24:01 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#16623
; Package
automake
.
(Mon, 03 Feb 2014 01:31:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16623 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org
:
bug#16623
; Package
automake
.
(Wed, 17 Dec 2014 22:13:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 16623 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org
:
bug#16623
; Package
automake
.
(Wed, 17 Dec 2014 23:43:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 16623 <at> debbugs.gnu.org (full text, mbox):
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
Added tag(s) patch.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 22 Dec 2014 10:17:01 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
16623 <at> debbugs.gnu.org and Peter Johansson <trojkan <at> gmail.com>
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 22 Dec 2014 10:17:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 19 Jan 2015 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 102 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.