Re: pkglibdir, pkgdatadir and program_transform_name

[Miles Bader]

Eric Blake  writes:
> I think it's worth pursuing a patch to the GNU Coding Standards that
> allows a standardized configure option that allows one to specify an
> alternate package name, so that things like $(pkglibdir) become
> $(libdir)/$(alternate_package_name)

A standardized option (described by the GNU Coding Standards) would
not be a bad idea, but of course there's no need to wait for that to
add the feature to autoconf... just having it there will help projects
like grub.  :]

-Miles

-- 
We live, as we dream -- alone

Re: automake 1.11.3 check-TESTS and command line length

[Eric Blake]

On 02/27/2012 12:52 PM, Stefano Lattarini wrote:
> [re-adding the relevant automake bug in CC]
> 
> Hi Peter, thanks for chiming in.
> 
> On 02/27/2012 12:15 PM, Peter Rosin wrote:
>>
>> I *think* the environment and the command line shares space (approx 64kB,

I can confirm this, based on my testing of Windows process spawning.

> So, basically, on MSYS, a:
> 
>   $ make TESTS="..."
> 
> invocation reduces the size available for the command lines of the make
> recipes, because the value of TESTS that gets exported in the environment
> eats away space that could be used by those command lines?  Oh joy ...

Yes.  Unlike on *ix systems, where argv and environ are independent
entities, Windows makes you deal with both limits at the same time, so
increasing the size of environ reduces the size permitted in argv.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: automake 1.11.3 check-TESTS and command line length

[Stefano Lattarini]

[re-adding the relevant automake bug in CC]

Hi Peter, thanks for chiming in.

On 02/27/2012 12:15 PM, Peter Rosin wrote:
>
> I *think* the environment and the command line shares space (approx 64kB,
> I repeat *think* here, I don't know the details off the top of my head, Cygwin
> isn't affected since it uses the cygwin DLL to communicate this stuff between
> cygwin processes using normal ipc mechanisms).  If I'm right, reducing the
> command line length for a process might sufficiently elevate the limit, even
> if it isn't eliminated.
> 
So, basically, on MSYS, a:

  $ make TESTS="..."

invocation reduces the size available for the command lines of the make
recipes, because the value of TESTS that gets exported in the environment
eats away space that could be used by those command lines?  Oh joy ...

Anyway, if we now reintroduce Ralf's patch, we will have a good explanation
of why it actually works.

Thanks,
  Stefano

Re: pkglibdir, pkgdatadir and program_transform_name

[Eric Blake]

On 02/27/2012 02:37 AM, Miles Bader wrote:
> Stefano Lattarini  writes:
>> Any transformation of a $(pkg*dir) by $(program_transform_name)
>> would be a bug; if you encounter such an issue, I'd be grateful if
>> you report it.
>>
>> But I'm pretty sure the inconsistency you are seeing here is due to
>> another reasons (maybe some Makefile.am or configure.ac settings
>> you're missing?)
> 
> When I was googling earlier (due to this same thread on the autoconf
> mailing list), I found patches to automake to _implement_ such a
> transformation posted to the grub mailing list... so maybe it's a
> modified version of automake.

I think it's worth pursuing a patch to the GNU Coding Standards that
allows a standardized configure option that allows one to specify an
alternate package name, so that things like $(pkglibdir) become
$(libdir)/$(alternate_package_name) - precisely because of situations
like grub vs. grub2 where there are two versions of the same package
'grub' but which are worth installing in parallel.  Allowing distro
package managers to install the two versions side-by-side by way of a
new standardized configure option for specifying the alternate package
name of the second installation, and then adding automake and/or
autoconf support for providing configure support for an alternate
package name, seems like it would be worthwhile for more than just grub.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: automake 1.11.3 check-TESTS and command line length

[Peter Rosin]

Stefano Lattarini skrev 2012-02-22 21:54:
> On 02/22/2012 09:22 PM, Bob Friesenhahn wrote:
>> On Wed, 22 Feb 2012, Stefano Lattarini wrote:

>>> I don't understand how that patch could actually work ...  If there are
>>> too many tests in $(TESTS), there will be too many logs in $(TEST_LOGS),
>>> and since the recipe for $(TEST_SUITE_LOG) contents the expansion of
>>> $(TEST_LOGS), the command line length limit for "/bin/sh -c" will be
>>> exceeded anyway ...
>>
>> I don't claim to understand how the patch functions other than
>> that it seems to delegate responsibility to a subordinate make.
>>
> Basically, it was trying (and succeeding!) to pass the list of tests
> to the subordinate make on the stdin rather than on the command line,
> to avoid hitting any command-line length limit.  It was a pretty
> simple and clever hack.  The problem is that the list of tests will
> still *have* to be finally expanded in the recipe that creates
> 'test-suite.log', at which point all our attempt to avoid exceeding
> command line length limits in recursive make invocations becomes
> useless, no matter how clever of fast.
> 
 A GNU make dependency would be a real problem.  A dependency on a
 properly-working standard make would not be such a problem.

>>> Is the test suite actually failing due to "exceeded command line length"
>>> on any system different from Cygwin or MinGW?  If not, I don't see how a
>>> GNU make dependency would be a problem (if not for the fact that it
>>> uglifies the already hideous patch even more).
>>
>> I have only observed it on MinGW/MSYS but that does not mean it will
>> not appear on some Unix OS with unusually short command line length.
>>
> True; but I say, let's cross that bridge when come at it :-)
> 
>> A GNU make dependency would be a problem if it depends on GNU make
>> for other systems.
>>
> This wouldn't be the case: the change causes the GNU make specific code
> to be used only if ./configure determines that the make program in use
> is GNU make.  Otherwise, the old implementation would still been used.
> So, no regression for the non-GNU makes (even if the pre-existing
> command-line length isse wouldn't have been fixed for them).
> 
>> On MinGW, /bin/sh throws an error but I don't recall that it provides
>> a useful diagnostic like "exceeded command line length".  It seemed
>> to me that the argument list was truncated.
>>
 I have not run into any problems when using Ralf's patch, but it apparently
 does not address all issues so Ralf backed it out.

>>> In fact, it fundamentally fails to address the issues -- that's why Ralf
>>> backed it out.
>>
>> All I know is that with the patch I did not experience a failure on any
>> system.
>>
> That's weird; clearly I'm missing something in the big picture here ...
> Maybe Peter can chime in with his MinGW expertise and save the day? ;-)

I *think* the environment and the command line shares space (approx 64kB,
I repeat *think* here, I don't know the details off the top of my head, Cygwin
isn't affected since it uses the cygwin DLL to communicate this stuff between
cygwin processes using normal ipc mechanisms).  If I'm right, reducing the
command line length for a process might sufficiently elevate the limit, even
if it isn't eliminated.

I'm no expert in that area...

Cheers,
Peter

Re: pkglibdir, pkgdatadir and program_transform_name

[Miles Bader]

Stefano Lattarini  writes:
> Any transformation of a $(pkg*dir) by $(program_transform_name)
> would be a bug; if you encounter such an issue, I'd be grateful if
> you report it.
>
> But I'm pretty sure the inconsistency you are seeing here is due to
> another reasons (maybe some Makefile.am or configure.ac settings
> you're missing?)

When I was googling earlier (due to this same thread on the autoconf
mailing list), I found patches to automake to _implement_ such a
transformation posted to the grub mailing list... so maybe it's a
modified version of automake.

-Miles

-- 
Immortality, n.  A toy which people cry for, And on their knees apply for,
  Dispute, contend and lie for, And if allowed Would be right proud
  Eternally to die for.

Re: pkglibdir, pkgdatadir and program_transform_name

[Stefano Lattarini]

On 02/26/2012 09:18 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Hello, all. In GRUB2 we have following problem: If
>
>  program_transform_name=s,grub,grub2
>
> then
>   pkglibdir=$libdir/grub2
>
Hmm... no, this is not automake's doing (automake is in fact not
documented to do so, and I've just added a test verifying that it
indeed does not do so -- see attachment).

> but
>   pkgdatadir=$datadir/grub2
>
You mean "pkgdatadir=$datadir/grub" here?  Anyway, this would be correct;
it's the "pkglibdir=$libdir/grub2" above that looks fishy.

> Is it intended or is it a bug?
>
Any transformation of a $(pkg*dir) by $(program_transform_name) would be
a bug; if you encounter such an issue, I'd be grateful if you report it.

But I'm pretty sure the inconsistency you are seeing here is due to
another reasons (maybe some Makefile.am or configure.ac settings you're
missing?)

HTH,
  Stefano
>From 848256f2d7057836be33e3abf84d082122a44c74 Mon Sep 17 00:00:00 2001
Message-Id: <848256f2d7057836be33e3abf84d082122a44c74.1330331593.git.stefano.lattar...@gmail.com>
From: Stefano Lattarini 
Date: Mon, 27 Feb 2012 09:28:47 +0100
Subject: [PATCH] coverage: --program-transform shouldn't transform too much
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Stemmed from a report by Vladimir 'φ-coder/phcoder' Serbinenko:


* tests/transform3.test: New test, checking that --program-transform
does not transform too much stuff (in particular, pkglibexecdir,
pgklibdir and pkgdatadir).
* tests/list-of-tests.mk: Add it.
* THANKS: Update.
---
 THANKS |1 +
 tests/list-of-tests.mk |1 +
 tests/transform3.test  |   87 
 3 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100755 tests/transform3.test

diff --git a/THANKS b/THANKS
index 7b7c9df..1bc3a80 100644
--- a/THANKS
+++ b/THANKS
@@ -370,6 +370,7 @@ Ulrich Eckhardt		eckha...@satorlaser.com
 Václav Haisman		v.hais...@sh.cvut.cz
 Vadim Zeitlin		vadim.zeit...@dptmaths.ens-cachan.fr
 Vincent Lefevre		vinc...@vinc17.org
+Vladimir Serbinenko	phco...@gmail.com
 Volker Boerchers	vboerch...@tecon.de
 Werner John		j...@oswf.de
 Werner Koch		w...@isil.d.shuttle.de
diff --git a/tests/list-of-tests.mk b/tests/list-of-tests.mk
index 89cff2f..0e5ee29 100644
--- a/tests/list-of-tests.mk
+++ b/tests/list-of-tests.mk
@@ -1144,6 +1144,7 @@ txinfo33.test \
 txinfo-unrecognized-extension.test \
 transform.test \
 transform2.test \
+transform3.test \
 uninstall-fail.test \
 uninstall-pr9578.test \
 unused.test \
diff --git a/tests/transform3.test b/tests/transform3.test
new file mode 100755
index 000..0fcf9bd
--- /dev/null
+++ b/tests/transform3.test
@@ -0,0 +1,87 @@
+#! /bin/sh
+# Copyright (C) 2002-2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# Make sure that --program-transform does not transform too much
+# stuff (in particular, pgklibdir, pkgdatadir and pkglibexecdir).
+
+required=cc
+. ./defs || Exit 1
+
+cat > configure.ac <<'END'
+AC_INIT([foo], [1.0])
+AM_INIT_AUTOMAKE
+AC_CONFIG_FILES([Makefile])
+AC_PROG_CC
+AM_PROG_AR
+AC_PROG_RANLIB
+AC_OUTPUT
+END
+
+cat > Makefile.am <<'END'
+bin_SCRIPTS = foo
+pkgdata_DATA = bar.txt
+pkglib_LIBRARIES = libzap.a
+pkglibexec_SCRIPTS = mu
+END
+
+cat > libzap.c <<'END'
+int zap (void)
+{
+  return 0;
+}
+END
+
+echo 'To be or not to be ...' > bar.txt
+
+cat > foo <<'END'
+#!/bin/sh
+exit 0
+END
+cp foo mu
+chmod a+x foo mu
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a
+
+./configure --program-prefix=gnu- --prefix "`pwd`/inst"
+
+$MAKE install
+find inst # For debugging.
+test -f inst/bin/gnu-foo
+test -x inst/bin/gnu-foo
+test -f inst/share/foo/bar.txt
+test ! -d inst/share/gnu-foo
+test -f inst/lib/foo/libzap.a
+test ! -d inst/lib/gnu-foo
+test -f inst/libexec/foo/gnu-mu
+test -x inst/libexec/foo/gnu-mu
+test ! -d inst/libexec/gnu-foo
+
+$MAKE uninstall
+test `find inst -type f -print | wc -l` = 0
+
+# Opportunistically test for installdirs.
+rm -rf inst
+$MAKE installdirs
+test -d inst/share/foo
+test ! -d inst/share/gnu-foo
+test -d inst/lib/foo
+test ! -d inst/lib/gnu-foo
+test -d inst/libexec/foo
+test ! -d inst/libexec/gnu-foo
+
+:
-- 
1.7.9