On 02/03/2014 12:23 AM, infirit wrote:
On Sun, 2 Feb 2014 18:56:01 +0100
infirit <infirit@xxxxxxxxx> wrote:
On Sun, 02 Feb 2014 23:21:03 +1000
Peter Johansson <trojkan@xxxxxxxxx> 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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
