bug#16623: PACKAGE vs PACKAGE_TARNAME

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#16623: PACKAGE vs PACKAGE_TARNAME

Peter Johansson-6
[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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/autoconf




Reply | Threaded
Open this post in threaded view
|

bug#16623: PACKAGE vs PACKAGE_TARNAME

infirit
On Sun, 02 Feb 2014 23:21:03 +1000
Peter Johansson <[hidden email]> 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.




Reply | Threaded
Open this post in threaded view
|

bug#16623: PACKAGE vs PACKAGE_TARNAME

infirit
On Sun, 2 Feb 2014 18:56:01 +0100
infirit <[hidden email]> wrote:

> On Sun, 02 Feb 2014 23:21:03 +1000
> Peter Johansson <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

bug#16623: PACKAGE vs PACKAGE_TARNAME

Peter Johansson-6
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




Reply | Threaded
Open this post in threaded view
|

bug#16623: PACKAGE vs PACKAGE_TARNAME

Stefano Lattarini
In reply to this post by infirit
On 02/03/2014 12:23 AM, infirit wrote:

> On Sun, 2 Feb 2014 18:56:01 +0100
> infirit <[hidden email]> wrote:
>> On Sun, 02 Feb 2014 23:21:03 +1000
>> Peter Johansson <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#16623: [PATCH] docs: improve description of ${PACKAGE}, ${VERSION}, and similar variables

Stefano Lattarini
In reply to this post by Peter Johansson-6
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 <[hidden email]>
---
 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                [hidden email]
 Ignacy Gawedzki                 [hidden email]
 Илья Н. Голубев                 [hidden email]
 Imacat                          [hidden email]
+Infirit                         [hidden email]
 Inoue                           [hidden email]
 Jack Kelly                      [hidden email]
 James Amundson                  [hidden email]
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