Hi everybody, On vr, 2015-02-06 at 10:46 +0100, Peter Rosin wrote: > On 2015-02-06 10:30, Gary V. Vaughan wrote: > > Hi Peter, > > > >> On Feb 6, 2015, at 9:22 AM, Peter Rosin <p...@lysator.liu.se> wrote: > >> > >>> On 2015-02-04 15:48, Bob Friesenhahn wrote: > >>>> On Wed, 4 Feb 2015, Robert Yang wrote: > >>>> > >>>> When reporting a bug, please describe a test case to reproduce it and > >>>> include the following information: > >>>> > >>>> host-triplet: $host > >>>> shell: $SHELL > >>>> compiler: $LTCC > >>>> compiler flags: $LTCFLAGS > >>>> linker: $LD (gnu? $with_gnu_ld) > >>>> version: $progname (GNU libtool) 2.4.5 > >>>> automake: `($AUTOMAKE --version) 2>/dev/null |$SED 1q` > >>>> autoconf: `($AUTOCONF --version) 2>/dev/null |$SED 1q` > >>> > >>> Perhaps libtool is accidentially executing 'automake --version' and > >>> 'autoconf --version' every time it is executed? That would certainly > >>> lead to a huge slowdown. > >> > >> That's it of course, how else could the variable be assigned? > > > > Only when --version is being serviced. > > Are you saying the a script with this line in it: > foo="`($AUTOCONF --version)`" > will delay the exec of $AUTOCONF until foo is expanded? > > I think not.
No, shell variable expansion is not delayed. Unlikey when used in `Makefile` with GNU make, where this *is* delayed until full expansion. > > >> But is it even useful information? I would expect that the autofoo > >> versions *at the time the package was created* is what matters? > > > > The information is useful in bug reports, and our instructions for > > reporting a bug to the list explicitly ask for the output from `libtool > > --version` which by including their other autotool versions makes > > reproducing the reporters environment a lot easier :-) > > But are the autofoo versions at libtool time really what we want > to know in bug reports? Again, I'd be much more interested in the > autofoo versions used to bootstrap the package. That might often > be the same thing, but when they are not confusion will ensue. AFAIK: Doesn't automake --version depend on the project's configure.ac? At least some distribution have an "automake-wrapper" which selects the automake version based on the project settings and fall-back to system default. e.g. Running "automake" (i.e. "automake-wrapper") when you have "automake-1.10", "automake-1.11" and "automake-1.12" installed: - Suppose system-default is automake-1.11 - When executed in directory *without* `configure.ac`: automake will run automake-1.11. - When executed in directory *with* configure.ac: - When automake version is *defined* to '1.10' in `configure.ac`, it will run "automake-1.10" - When automake version is *defined* to '1.12' in `configure.ac`, it will run "automake-1.12" - When automake version is *not defined* in `configure.ac`, it will run "automake-1.11" With best regards, Tom. > > Cheers, > Peter > > > _______________________________________________ > https://lists.gnu.org/mailman/listinfo/libtool -- ________________________________________________________________________ | tom.ghyseli...@excentis.com | | Tom Ghyselinck | Senior Engineer | Excentis N.V. | Gildestraat 8 B-9000 Ghent, Belgium | Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 ________________________________________________________________________ _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool