bug#16623: PACKAGE vs PACKAGE_TARNAME

[Stefano Lattarini]

On 02/03/2014 12:23 AM, infirit wrote:
> On Sun, 2 Feb 2014 18:56:01 +0100
> infirit <address@hidden> wrote:
> > On Sun, 02 Feb 2014 23:21:03 +1000
> > Peter Johansson <address@hidden> 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