missing fi for compilation to .obj
This patch comes from a problem reported to jikes. I'm using the cygwin version of automake, which recently upgraded to automake 1.7.1 (from automake 1.6). After regenerating Makefile.in, the makefile now has this line: @am__fastdepCXX_TRUE@ -c -o $@ `if test -f '$<'; then $(CYGPATH_W) '$<'; else $(CYGPATH_W) '$(srcdir)/$<'`; \ Notice the missing fi inside the backticks. I don't have the automake sources in front of me, but the file to patch gets installed as /usr/share/automake/am/depend2.am. 2002-11-14 Eric Blake <[EMAIL PROTECTED]> * am/depend2.am: Add missing fi in c.obj rule. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer --- depend2.am.bak 2002-11-14 08:16:26.0 -0700 +++ depend2.am 2002-11-14 08:18:00.0 -0700 @@ -62,7 +62,7 @@ if %COMPILE% -MT %OBJOBJ% -MD -MP -MF "%DEPBASE%.Tpo" \ ## Ugly invocation here; using a variable fails due to a parsing ## problem in automake. - %-c% -o %OBJOBJ% `if test -f '%SOURCE%'; then $(CYGPATH_W) '%SOURCE%'; else $(CYGPATH_W) '$(srcdir)/%SOURCE%'`; \ + %-c% -o %OBJOBJ% `if test -f '%SOURCE%'; then $(CYGPATH_W) '%SOURCE%'; else +$(CYGPATH_W) '$(srcdir)/%SOURCE%'; fi`; \ then mv "%DEPBASE%.Tpo" "%DEPBASE%.Po"; \ else rm -f "%DEPBASE%.Tpo"; exit 1; \ fi @@ -72,8 +72,8 @@ depfile='%DEPBASE%.Po' tmpdepfile='%DEPBASE%.TPo' @AMDEPBACKSLASH@ $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@ endif %AMDEP% -?-o? %COMPILE% %-c% %-o% %OBJOBJ% `if test -f '%SOURCE%'; then $(CYGPATH_W) '%SOURCE%'; else $(CYGPATH_W) '$(srcdir)/%SOURCE%'` -?!-o? %COMPILE% %-c% `if test -f '%SOURCE%'; then $(CYGPATH_W) '%SOURCE%'; else $(CYGPATH_W) '$(srcdir)/%SOURCE%'` +?-o? %COMPILE% %-c% %-o% %OBJOBJ% `if test -f '%SOURCE%'; then $(CYGPATH_W) +'%SOURCE%'; else $(CYGPATH_W) '$(srcdir)/%SOURCE%'; fi` +?!-o? %COMPILE% %-c% `if test -f '%SOURCE%'; then $(CYGPATH_W) '%SOURCE%'; else +$(CYGPATH_W) '$(srcdir)/%SOURCE%'; fi` endif !%FASTDEP% if %?LIBTOOL%
make -k fails on cygwin [Was: Test failures in coreutils-5.3.0 on cygwin]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[cross-posted to cygwin and automake lists]
I'm not sure if the bug below is with cygwin's mods to make, in automake
for using non-portable Makefile constructs, or in both.
According to Jim Meyering on 1/12/2005 9:45 AM:
>>>If you run `make -k check', it will keep going in spite of failures.
>
>> Nope, even with `make -k check', my run ends in:
>> ==
>> 1 of 5 tests failed
>> Please report to bug-coreutils@gnu.org
>> ==
>> make[3]: *** [check-TESTS] Error 1
>> make[3]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp'
>> make[2]: *** [check-am] Error 2
>> make[2]: Target `check' not remade because of errors.
>> make[2]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp'
>> make[1]: *** [check-recursive] Error 1
>> make[1]: Target `check' not remade because of errors.
>> make[1]: Leaving directory `/home/eblake/coreutils-5.3.0/tests'
>> make: *** [check-recursive] Error 1
>> make: Target `check' not remade because of errors.
>
> Then you should use a make program that honors the -k option.
> There must be a GNU make port to cygwin.
It _is_ GNU make, but with cygwin modifications to accept --unix or
- --win32 to determine whether to use /bin/sh or the native DOS shell:
$ make --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
$ cat Makefile
all:
@echo ${MAKEFLAGS}
$ make
- --unix
$ make -k
- --unix -k
Now look at what automake 1.9 sticks in to the Makefiles for recursive
traversal:
$(RECURSIVE_TARGETS):
@set fnord $$MAKEFLAGS; amf=$$2; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
dot_seen=yes; \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;;
esac; \
done; \
if test "$$dot_seen" = "no"; then \
$(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
Whoops - $amf is set to --unix, rather than the desired '' or -k. The
case statement fails, and the recursive traversal of subdirs halts in
spite of my request to keep going. As pointed out last month on the
libtool lists,
http://lists.gnu.org/archive/html/libtool-patches/2004-12/msg00091.html,
parsing $MAKEFLAGS is inherently non-portable. `info make' also has a
page dedicated to "Phony Targets" that discusses the more portable way to
have a recursive target, although I don't know how well it scales to the
more than 15 recursive targets that automake creates.
SUBDIRS = foo bar baz
.PHONY: subdirs $(SUBDIRS)
subdirs: $(SUBDIRS)
$(SUBDIRS):
$(MAKE) -C $@
foo: baz
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB50kf84KuGfSFAYARAmEdAKCTjFJlAWmPR9lDboMyGi8r2hiQNwCfaeQg
D/EyY+pF1kLs8c2LfOqD5O8=
=Elu+
-END PGP SIGNATURE-
Re: make -k fails on cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Alexandre Duret-Lutz on 1/15/2005 6:35 AM: > How about the following patch to Automake? > > 2005-01-15 Alexandre Duret-Lutz <[EMAIL PROTECTED]> > > * lib/am/subdirs.am ($(RECURSIVE_TARGETS), mostlyclean-recursive, > clean-recursive, distclean-recursive, maintainer-clean-recursive): > Process all words of $MAKEFLAGS when checking for -k. > * tests/check4.test: New file. > * tests/Makefile.am (TESTS): Add check4.test. > Report from Eric Blake. I verified that `make -k' worked on cygwin after applying this patch to automake CVS head, and running autoreconf on coreutils to incorporate the patch. Thanks for a quick fix. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB6aS984KuGfSFAYARAi7CAKDCF3FNR/JOOzVvlXmI6rqdG0gKowCfVFP8 1RFnW/Lv5sglCO01AV4B8ok= =T+x8 -END PGP SIGNATURE-
Re: Makefile.in not generated using Automake
[followups can drop autoconf, as this is an automake-only question] On 06/14/2011 02:12 AM, Rushabh Doshi wrote: > > > $ automake --add-missing > configure.ac:6: installing `./install-sh' > configure.ac:6: installing `./missing' > Makefile.am: installing `./INSTALL' > Makefile.am: required file `./NEWS' not found ... > $ ls > aclocal.m4 autoscan.log configure.ac depcomp INSTALL Makefile.am > autom4te.cache config.h.in COPYING hello.c install-sh missing There's your problem - you blindly ignored the error message from automake and failed to check for non-zero exit status. Automake won't produce Makefile.in if required files are missing. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Weird behaviour of AM_CONDITIONAL
On 09/02/2011 08:24 AM, Thibaut Le Guilly wrote: I am using AM_CONDITIONAL to enable a user to choose between one kind of library and another one with : AM_CONDITIONAL([ENABLE_A], [test x$condition=xyes]) > Am I doing something wrong? Do you know how to solve this problem? Wrong syntax. You meant: test "x$condition" = xyes the quoting around $condition, and the spacing around =, are essential in shell syntax. Otherwise, if $condition has no whitespace to cause IFS word splitting, you end up testing whether the single word x$condition=xyes is non-empty, which it is, so the test is always true. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
On 11/16/2011 06:04 PM, Gary V. Vaughan wrote: > Right, and even when I wrote the dubious comment quoted above in 2003, other > parts of libtool were still using macro expansions in make targets, so I think > the whole thing is probably a red herring. Libtool has never fully supported > any make that can't deal with macros in targets, and we've never received a > complaint or bug report, which makes me think that if such a make exists, no > one wants to use it with libtool, so we can safely ignore the whole thing. > > The NEWS entry I wrote for this commit is purely for future repo archaeology. Then it's not NEWS-worthy. It's worth keeping that analysis in the git commit message (as you say, for repo archaeology), but let's limit it to just there, rather than potentially causing users to worry about some perceived loss of portability when they read NEWS. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10237: AM_SILENT_RULES does not work with NonStop make
On 12/07/2011 01:54 PM, Roumen Petrov wrote: >> Exactly. Hence the proposal for a configure-time check, which expands >> to the extension where the extension was tested to work, and which >> expands to an innocuous variant that avoids nested variables where the >> test fails. >> > > I remember one old discussion from automake list that end with following > solution > lib_LTLIBRARIES = @MODULE@.la > @MODULE@_la_SOURCES = module.c > @MODULE@_la_LDFLAGS = -module -avoid-version How is that relavant to this bug? The whole point of Paul's proposal is that @AM_V@ and @AM_DEFAULT_VERBOSITY@ are automake internals, and appear only in Makefile.in, not Makefile.am. > > Following current discussion I think that next will be automake to be > able to process following Makefile.am > > MODULE = @MODULE@ > lib_LTLIBRARIES = $(MODULE).la > $(MODULE)_la_SOURCES = module.c > $(MODULE)_la_LDFLAGS = -module -avoid-version You're asking for something different, which is a smarter automake that can handle Makefile.am in such a way that it can see through a user-provided @MODULE@, even when it is later spelled $(MODULE). But that is unrelated to fixing AM_SILENT_RULES to produce POSIX-compliant makefiles. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#8071: Please rename automake invocation node
On 12/28/2011 12:33 PM, Stefano Lattarini wrote:
>> > This can be fixed by using an @anchor{} to the old name at the same
>> > location as you switch to the new consistent node name. The tools will
>> > then keep the old link live by virtue of the anchor, without having to
>> > mess with .symlinks.
>> >
> Good idea. What about the attached patch? I'm not very familiar with
> the translation of @anchor directives in the HTML output, so I'd like an
> explicit ACK before pushing.
>
>
> -
> -@node Invoking Automake
> +@c The anchor is required to avoid breaking existing web hyperlinks
> +@c still using the old name of this node.
> +@anchor{Invoking automake}
> +@node automake Invocation
> @chapter Creating a @file{Makefile.in}
Autoconf has this example:
@node Specifying Target Triplets
@section Specifying target triplets
@cindex System type
@cindex Target triplet
@c This node used to be named Specifying Names. The @anchor allows old
@c links to still work.
@anchor{Specifying Names}
I'm not sure if putting the @anchor after the @node make a difference.
If the anchor takes the old name to the previous node, then we may want
to move the anchor to appear after the @node.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
RFC: cool hack for simplifying do_subst generation of scripts
I was chatting with Federico on IRC about a way to avoid duplication between Makefile.am and configure.ac. His particular case had a script file that wanted a few full substitutions (which implies a make-time substitution, per [1]), but he didn't want to have to copy the whole list of AC_SUBST from configure.ac into Makefile.am in his do_subst script, and didn't want to build a file.in.in that goes through configure AC_CONFIG_FILES only to have file.in then go through a make-time expansion. We came up with the autoconf-documented use of $(top_builddir)/config.status --file=- (from [2]). And to demonstrate the ease of use, I've done this preliminary patch against automake itself. Is this something we are interested in doing (since it _does_ provide a reduced maintenance burden, where adding a new AC_SUBST that does not need make-time expansion can now be done in just one file instead of two)? And if so, should I expand this RFC patch into something that passes the testsuite as well as mentioning it in the automake manual? [For the purposes of my quick test, I started a 'make check', still underway as I type this, and noticed that at least aclocal5.test failed, but everything else through f90only.test is happy so far. But I won't bother to investigate failures unless we decide to go forward with this plan.] [1] https://www.gnu.org/software/automake/manual/html_node/Scripts.html [2] https://www.gnu.org/software/autoconf/manual/autoconf.html#config_002estatus-Invocation diff --git i/Makefile.am w/Makefile.am index 8fe9c0f..0ef39c1 100644 --- i/Makefile.am +++ w/Makefile.am @@ -67,21 +67,11 @@ uninstall-hook: done -## We can't use configure to do the substitution here; we must do it -## by hand. We use a funny notation here to avoid configure -## substitutions in our text. +## We want a handful of substitutions to be fully-expanded by make; +## then use config.status to substitute the remainder where a single +## expansion is sufficient. We use a funny notation here to avoid +## configure substitutions in our text. do_subst = sed \ - -e 's,[@]APIVERSION[@],$(APIVERSION),g' \ - -e 's,[@]PACKAGE[@],$(PACKAGE),g' \ - -e 's,[@]PACKAGE_BUGREPORT[@],$(PACKAGE_BUGREPORT),g' \ - -e 's,[@]PACKAGE_URL[@],$(PACKAGE_URL),g' \ - -e 's,[@]PATH_SEPARATOR[@],$(PATH_SEPARATOR),g' \ - -e 's,[@]PERL[@],$(PERL),g' \ - -e 's,[@]PERL_THREADS[@],$(PERL_THREADS),g' \ - -e 's,[@]SHELL[@],$(SHELL),g' \ - -e 's,[@]am_AUTOCONF[@],$(am_AUTOCONF),g' \ - -e 's,[@]am_AUTOM4TE[@],$(am_AUTOM4TE),g' \ - -e 's,[@]VERSION[@],$(VERSION),g' \ -e 's,[@]configure_input[@],Generated from $@.in; do not edit by hand.,g' \ -e 's,[@]datadir[@],$(datadir),g' @@ -92,7 +82,7 @@ automake: automake.in aclocal: aclocal.in automake aclocal: Makefile rm -f $@ $@.tmp - $(do_subst) $(srcdir)/$@.in >$@.tmp + $(do_subst) $(srcdir)/$@.in | ./config.status --file=- >$@.tmp chmod +x $@.tmp chmod a-w $@.tmp mv -f $@.tmp $@ -- 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.2b test release
On 01/27/2012 01:08 PM, NightStrike wrote: > On Thu, Jan 26, 2012 at 1:47 AM, Ralf Corsepius > wrote: >>> - The support for the "obscure" multilib feature has been deprecated, >>> and will be moved out of the automake core in the next major Automake >>> release (1.12). >> >> Bummer - Please reconsider this and understand that politliness prohibits me >> to furtherly comment on this. > > Seconded. Moving multilib files out of the core does not mean that it is being permanently broken, it only means that you have to start pulling in the contrib directory if you want to use multilib. That is, we're not killing the feature entirely, we're only splitting it out of automake proper into its own project, where it will hopefully get more attention than what the current level it is getting while embedded in automake. Re-read the list where we discussed this - gcc is doing a better maintenance job of multilib support in the first place, so this move is intended to point you towards the better-maintained source in the first place. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: *simple* example using Autotest
On 02/07/2012 03:08 PM, Robert Boehne wrote: > All, > > I'd like to start using Autotest in a project (that needs is badly) but > the full-featured GNU M4 example is a bit hard to wrap my head around. > Can anyone suggest another project I could look at as an example, that > has more basic/rudimentary Autotest use? Automake is probably the wrong list to ask, since autotest is provided by autoconf, and automake isn't using autotest. But here are several projects I know of that use autotest: autoconf itself m4 bison libtool some of them easier than others to figure out, but that should hopefully help you get started on seeing how others have used it. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: pkglibdir, pkgdatadir and program_transform_name
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
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: should an empty "pkgdata_DATA" cause creation of $(pkgdatadir) by "make install"?
On 03/13/2012 08:55 AM, Robert Boehne wrote: >> >> So we're in a sort of a tie here: some users think that the current >> Automake >> behaviour is a feature (and I lean toward that position), other ones >> (with >> Ralf among them, apparently) believe it's a bug. Hmmm. What now? >> >> Regards, >>Stefano > > I would agree with the "feature" camp. Users should be able to create > an empty $(pkgdatadir) - suppose that empty directory is populated by > other methods. They should also be able to not create $(pkgdatadir) as > well as a non-empty $(pkgdatadir). I like the idea of installing empty directories by default, as a feature, but can also see the arguments for omitting a directory. What about a compromise: By default, we create the empty directory: pkgdata_DATA = But with the noinst flag, a directory can be specifically marked for no creation unless it later has contents: noinst_pkgdata_DATA = For the sake of conditional concatenation, we should either allow: noinst_pkgdata_DATA = if COND pkgdata_DATA += file endif or else make the documentation explicit that to conditionally install contents to a directory, but to omit the directory if no contents are present, then you must do: noinst_pkgdata_DATA = pkgdata_DATA = if COND pkgdata_DATA += file endif Either way, the semantics are that if there are contents in a directory, then the directory is created; if the conditions make it so there are no contents in a directory, then the directory is created _unless_ the noinst_ prefix also appeared with that directory. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Don't distribute auto*tools output; do distribute autoreconf input
On 05/10/2012 01:14 PM, Paul Elliott wrote: > > I want the people that receive my tarball to do autoreconf. Their system's > autoconf-archive may be more up-to date than mine. > > What is the best way to tell automake not to distribute (i.e. put in > tarball), > all the files created by autoreconf, ./configure? ./configure must be put in the tarball (otherwise, you are _forcing_ your end users to use autoconf, but the whole point of autoconf is to make it so that your end users can run configure without having autoconf installed on their machine). However, ./configure need not be stored in your VCS. If what you are really asking is how to avoid generated files in your VCS, so that people developing your package (those that check out from your VCS, rather than end users that build from your tarball) must regenerate the files with their version of the tool, then that's a question that depends on your choice of VCS. Autoconf is such a project, where generated files such as ./configure are part of the tarball but not part of the VCS. > I especially do not want to distribute aclocal.m4 or files that contain it's > info. I want the build system to get up-to-date files from its > autoconf-archive > files. > > I note these files are usually distributed by default, even though no dist_ > statement is asking for them. > > Will it work to put the unwanted files in nodist_prog_SOURCES? > Is there a canonical way to do this? No, because the moment you quit distributing these files, you have required end users to have more tools available than normally required by the GNU Coding Standards to even be able to use your tarball. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[PATCH] config: drop scripts that automake says are not independent
These three scripts are too closely tied to automake internals to be independently useful. In fact, automake would rather that people did not mix the latest version of these scripts with older versions of automake, as there is no effort being put into maintaining backwards-compatibility when these scripts are updated. * config/srclist.txt: Drop elisp-comp, missing, and ylwrap. * build-aux/elisp-comp: Delete. * build-aux/missing: Likewise. * build-aux/ylwrap: Likewise. Signed-off-by: Eric Blake --- Any objections to this patch? ChangeLog|8 ++ build-aux/elisp-comp | 93 build-aux/missing| 214 -- build-aux/ylwrap | 232 -- config/srclist.txt |3 - 5 files changed, 8 insertions(+), 542 deletions(-) delete mode 100755 build-aux/elisp-comp delete mode 100755 build-aux/missing delete mode 100755 build-aux/ylwrap diff --git a/ChangeLog b/ChangeLog index ebbc96b..228383c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2012-06-26 Eric Blake + + config: drop scripts that automake says are not independent + * config/srclist.txt: Drop elisp-comp, missing, and ylwrap. + * build-aux/elisp-comp: Delete. + * build-aux/missing: Likewise. + * build-aux/ylwrap: Likewise. + 2012-06-24 Bruno Haible ptsname_r: Make it consistent with ptsname on AIX. diff --git a/build-aux/elisp-comp b/build-aux/elisp-comp deleted file mode 100755 index 7766db4..000 --- a/build-aux/elisp-comp +++ /dev/null @@ -1,93 +0,0 @@ -#!/bin/sh -# Copyright (C) 1995-2012 Free Software Foundation, Inc. - -scriptversion=2010-02-06.18; # UTC - -# Franc,ois Pinard , 1995. -# -# 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 <http://www.gnu.org/licenses/>. - -# As a special exception to the GNU General Public License, if you -# distribute this file as part of a program that contains a -# configuration script generated by Autoconf, you may include it under -# the same distribution terms that you use for the rest of that program. - -# This file is maintained in Automake, please report -# bugs to or send patches to -# . - -case $1 in - '') - echo "$0: No files. Try '$0 --help' for more information." 1>&2 - exit 1; - ;; - -h | --h*) -cat <<\EOF -Usage: elisp-comp [--help] [--version] FILES... - -This script byte-compiles all '.el' files listed as FILES using GNU -Emacs, and put the resulting '.elc' files into the current directory, -so disregarding the original directories used in '.el' arguments. - -This script manages in such a way that all Emacs LISP files to -be compiled are made visible between themselves, in the event -they require or load-library one another. - -Report bugs to . -EOF -exit $? -;; - -v | --v*) -echo "elisp-comp $scriptversion" -exit $? -;; -esac - -if test -z "$EMACS" || test "$EMACS" = "t"; then - # Value of "t" means we are running in a shell under Emacs. - # Just assume Emacs is called "emacs". - EMACS=emacs -fi - -tempdir=elc.$$ - -# Cleanup the temporary directory on exit. -trap 'ret=$?; rm -rf "$tempdir" && exit $ret' 0 -do_exit='(exit $ret); exit $ret' -trap "ret=129; $do_exit" 1 -trap "ret=130; $do_exit" 2 -trap "ret=141; $do_exit" 13 -trap "ret=143; $do_exit" 15 - -mkdir $tempdir -cp "$@" $tempdir - -( - cd $tempdir - echo "(setq load-path (cons nil load-path))" > script - $EMACS -batch -q -l script -f batch-byte-compile *.el || exit $? - mv *.elc .. -) || exit $? - -(exit 0); exit 0 - -# Local Variables: -# mode: shell-script -# sh-indentation: 2 -# eval: (add-hook 'write-file-hooks 'time-stamp) -# time-stamp-start: "scriptversion=" -# time-stamp-format: "%:y-%02m-%02d.%02H" -# time-stamp-time-zone: "UTC" -# time-stamp-end: "; # UTC" -# End: diff --git a/build-aux/missing b/build-aux/missing deleted file mode 100755 index 06e0af1..000 --- a/build-aux/missing +++ /dev/null @@ -1,214 +0,0 @@ -#! /bin/sh -# Common wrapper for a few potentially missing GNU programs. - -scriptversion=2012-06-14.10; # UTC - -# Copyright (C) 1996-2012 Free Software
Re: [PATCH] config: drop scripts that automake says are not independent
[adding autoconf] On 06/26/2012 12:26 PM, Bruno Haible wrote: > Eric Blake wrote: >> * build-aux/elisp-comp: Delete. > > What about modules/elisp-comp? That module has only had one edit: it's introduction in 2006: https://lists.gnu.org/archive/html/bug-gnulib/2006-08/msg00248.html with a claim that autoconf needs it. But autoconf uses automake, and can get the file from automake, if it really needs it. For that matter, WHY does autoconf need it? Looking at 'git grep -l elisp-comp', I see: .gitattributes .gitignore ChangeLog.3 cfg.mk which means the ONLY mention of elisp-comp is historical or version-control, other than the cfg.mk listing that syncs the file. It appears that autoconf itself does not either use or advertise the existence of elisp-comp, so I will be fixing autoconf to delete the syncing of the file. On the unlikely chance that someone was relying on autoconf (rather than automake) as their upstream source for elisp-comp, I will also include a NEWS entry as part of that effort. For gnulib, I therefore think it is appropriate to completely delete modules/elisp-comp, unless someone speaks up with some evidence of a package that is actively relying on the module. Again, a NEWS entry pointing to automake would be appropriate. I'll respin the gnulib patch accordingly. > >> * build-aux/ylwrap: Likewise. > > OK. Many packages (gettext-runtime/intl, parse-datetime, ...) rely directly > on bison. Only packages which support old yacc need this wrapper script, and > they typically use Automake. And not mentioned in my proposed commit message, but I specifically kept mdate-sh as one of the mirrored files, even though Stefano originally suggested that it might be automake-centric; that particular script is small enough to be useful in a standalone context. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: distinguish automake 1.11 from 1.12+ at autoconf time
On 08/06/2012 05:29 PM, Peter Johansson wrote: > Hi, > > I'd like to distinguish automake 1.11 from 1.12 (or later) at autoconf > time. I wonder is there's any documented macro that was introduced in > 1.12 that I could use to m4_ifdef? If nothing else, the autoconf philosophy of feature checks being better than version checks should guide your decision here. What _specific_ feature are you using from 1.12 that wasn't present in 1.11? Or put another way, either your configure.ac works equally well with both versions (so you don't care which version), or there's something you do with 1.12 that doesn't work with 1.11 and therefore you are trying to make it conditional so that 1.11 can still process the rest of the file. Determine that feature, and we are that much closer to helping you conditionalize your configure.ac to work with both versions. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
v1.11.6 tag missing from automake.git?
I see v1.12.2, but no tag for v1.11.6 for the CVE-2012-3386 fix. Is this intentional? -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: v1.11.6 tag missing from automake.git?
On 08/14/2012 04:24 PM, Stefano Lattarini wrote: > Hi Eric. > > On 08/15/2012 12:16 AM, Eric Blake wrote: >> I see v1.12.2, but no tag for v1.11.6 for the CVE-2012-3386 fix. >> > Hmm... I can see it without problems: > > <http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.6> > > User error on your part, or am I missing something? I blame 'git remote update origin' for not pulling all tags that are not also reachable from a current branch; and since origin/branch-1.11 is no longer maintained, I no longer have a branch spec to pull in the new label by default. I had to do an explicit 'git fetch --tags origin' to get it, but now I see the label again. It really IS a good practice to keep a branch associated with all public long-lived tags; it doesn't waste any additional space in the git repo, and makes fetches pick up those tags with less effort. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Automake-NG] Automake vs. Automake-NG
On 08/21/2012 10:30 AM, Ralf Corsepius wrote: >>> And I've done that already where possible and reasonable. For example, >>> the 'silent-rules' option is now active by default, and the tags-related >>> rules have been reworked and improved. > > Well, from a distro maintainer's view this a bad idea. Ralf, how many times do we have to tell you? Setting the automake option 'silent-rules' does NOT make the build silent by default, it merely enables the possibility of a silent build. Remember, when 'silent-rules' was first implemented, we did it with an implementation that violated POSIX make, and so we made it optional whether your Makefile would work on 95% of make implementations by supporting silent rules at the expense of POSIX (you, the end user, still decide whether to be silent or noisy), or whether your Makefile would work on 100% of make implementations but lack the ability to configure silent vs. noisy (you, the end user, have no choice). Since that original implementation, we came up with a way to make silent rules configurable in a manner compliant with 100% of make implementations, without violating POSIX. Therefore, we can now ALWAYS emit the automake code that allows you, the end user, a choice between silent or noisy. It is still up to individual packages whether the build will be silent or noisy by default, and it remains something that you can override package defaults with a config.site that forces noisy builds. The 'silent-rules' change in automake change did NOT make more builds instantly silent, nor are we preventing you from your goal of noisy builds for the Fedora buildbots. Quit beating a dead horse to spread FUD about something which is not true. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] {master} compile: remove support for $(INCLUDES)
On 08/22/2012 09:12 AM, Stefano Lattarini wrote: >>From 54a49542d417850e646fefe7bad56546a2362449 Mon Sep 17 00:00:00 2001 > Message-Id: > <54a49542d417850e646fefe7bad56546a2362449.1345648257.git.stefano.lattar...@gmail.com> > From: Stefano Lattarini > Date: Wed, 22 Aug 2012 16:40:15 +0200 > Subject: [PATCH] compile: remove support for $(INCLUDES) > > It has already been deprecated in the manual and by warnings in the > 'obsolete' categories for ages (at least since 2003), in favour of > AM_CPPFLAGS. Automake-NG has removed support for it already. > > So, by removing it in Automake 1.13, we will simplify the transition > path for people that want to switch to Automake-NG. What a bummer for packages like libvirt that strive to be buildable from git on both RHEL 5 (requires INCLUDES, since automake 1.9.6 is still the current version there) as well as Fedora rawhide (where removing support for INCLUDES entirely will force the issue over to AM_CPPFLAGS). It means I'll have to come up with some compatibility hacks in order to share one Makefile.am among both automake versions. Or maybe I'll just give up and say that libvirt can no longer be bootstrapped on RHEL 5 (it can still be developed there, but only if you bootstrap somewhere else and then 'make dist' and develop on the distributed tarball). At any rate, I'm fine taking the burden of trying to support cross-automake versioning in order to cater to the fact that enterprise systems are still stuck on ancient automake, but a little help from automake would make it easier. I'd much rather a mandatory noisy warning period before a feature is completely removed. Yes, you've warned, but the warning wasn't mandatory, so no one has been forced to come up with workarounds yet. It is only once people have the workarounds in place that it is safe to remove the feature; I think that argues that you can't remove INCLUDES until 1.14, but that 1.13 should make the warning unconditional. It would also be nice if you provided a feature that could be probed at m4 time in order to write a configure.ac that can then set an automake conditional, so that Makefile.am can then set either INCLUDES or AM_CPPFLAGS as appropriate within the two branches of the conditional. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] {master} compile: remove support for $(INCLUDES)
On 08/22/2012 03:52 PM, Stefano Lattarini wrote: > OTOH, I believe developers working on older systems should be ready to > install more recent developer tools once in a while. You can't truly > expect not to update your Automake installation for 3, 4 years! Oh, _I_ fully wish that RHEL 5 would at least update the core toolchain (in fact, these links [1],[2] make it look like Red Hat is working towards a solution of supporting parallel toolchains, with a modern toolchain installed alongside the stable distro toolchain even for older RHEL). But the fact remains that Enterprise systems tend to lag very far behind the curve, and so you have a tradeoff of whether to support development on such old systems, or merely support the released product on old systems while requiring development on newer systems. At the end of the day, it boils down to a question of whether upgrading the toolchain would risk introducing FTBFS to some critical piece of in-house software, and enterprise customers frown at risk, so they really do use 3 and 4-year-old automake solutions. [1] https://www.redhat.com/developers/rhel/ [2] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Developer_Toolset/1/html/User_Guide/chap-Red_Hat_Developer_Toolset.html#sect-Red_Hat_Developer_Toolset-About -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [libvirt] libvirt build failure w/GNU make and automake.git (automake regression?)
On 09/12/2012 09:01 AM, Jim Meyering wrote:
> When I run ./autogen.sh && make, I see this:
> (this arose because I had the latest automake.git/master tools --
> commit c1b83e1af60b866cf5cdeebf77d0275019bad8b2 from today --
> early in my path)
>
> Making all in tests
> make[2]: Entering directory `/h/j/w/co/libvirt/tests'
> Makefile:4355: *** Malformed target-specific variable definition. Stop.
>
> The trouble is that "undefine" is an operator in GNU make.
> The most pragmatic work-around is to rename the "undefine" test script.
Indeed - while the upstream debate continues on whether 'make',
'automake', or both should be patched to allow 'undefine', downstream in
libvirt, I am pushing this trivial patch:
From a20f06d9d9b0353d7fb7a8e11a631253d5961b96 Mon Sep 17 00:00:00 2001
From: Eric Blake
Date: Wed, 12 Sep 2012 11:25:51 -0600
Subject: [PATCH] build: avoid confusing make with raw name 'undefine'
Make has a builtin operator 'undefine', and coupled with latest
automake.git, this test name ended up confusing make into thinking
the file name was meant to be used as the make operator. Renaming
the file avoids the confusion.
* tests/undefine: Rename...
* tests/virsh-undefine: ...to this.
* tests/Makefile.am (test_scripts): Use new name.
Reported by Jim Meyering.
---
tests/Makefile.am | 10 ++
tests/{undefine => virsh-undefine} | 0
2 files changed, 6 insertions(+), 4 deletions(-)
rename tests/{undefine => virsh-undefine} (100%)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index bec89e2..c5cecaa 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -182,12 +182,13 @@ test_scripts += \
read-bufsiz \
read-non-seekable \
start \
- undefine\
vcpupin \
virsh-all \
virsh-optparse \
virsh-schedinfo \
- virsh-synopsis
+ virsh-synopsis \
+ virsh-undefine \
+ $(NULL)
test_programs += \
eventtest \
@@ -203,12 +204,13 @@ EXTRA_DIST += \
read-bufsiz \
read-non-seekable \
start \
- undefine\
vcpupin \
virsh-all \
virsh-optparse \
virsh-schedinfo \
- virsh-synopsis
+ virsh-synopsis \
+ virsh-undefine \
+ $(NULL)
endif
if WITH_SECDRIVER_APPARMOR
diff --git a/tests/undefine b/tests/virsh-undefine
similarity index 100%
rename from tests/undefine
rename to tests/virsh-undefine
--
1.7.11.4
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Pre-built binary package
On 09/20/2012 11:56 AM, Too, Justin A. wrote: > Hi Baurzhan, > > On 9/20/12 10:52 AM, "Baurzhan Ismagulov" wrote: > >> On Thu, Sep 20, 2012 at 10:24:28AM -0700, Too, Justin A. wrote: >>> I would like to build and distribute a pre-built binary package for my >>> project >> >> For which OS / distribution? > > For example: Linux (rhel5/6) and Ubuntu. Those are different distros, and therefore have different rules on how to package binaries. You sound like you're trying to reinvent yourself as a distro. My advice: don't. Let the distros package binaries, and you focus on distributing source. The ONLY way you can expect to ship a pre-built binary in your tarball and have it work for all possible users installing your tarball is if your binary is architecture and OS-independent (such as java bytecode). In all other cases, it makes more sense for the user to build the binary themselves from the source (where user includes major distros, who will then package it up in .rpm or apt formats as appropriate for the distro, and where the distro package-manager software like yum or apt-get can then be used to install that binary in desired locations). -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: apt-get/yum like dependency installation in autotool
On 10/23/2012 11:19 AM, Dan Kegel wrote: > On Tue, Oct 23, 2012 at 9:05 AM, Rudra Banerjee wrote: >> I don't know if this is asking too much from autotools, but is it anyway >> possible to install missing dependency files via autotools? >> say, in my program, I use libsoup as >> #include >> >> is it possible for autotools to install libsoup if it is missing? > > offhand, I'd say that's beyond the scope of autotools, Agreed. You're not the first person to ask, and this earlier thread should give you more clues why autotools is not the place to do this: https://lists.gnu.org/archive/html/bug-autoconf/2012-09/msg00049.html -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: looking for a good example of non-recursive Make using project
On 11/19/2012 12:51 AM, NightStrike wrote:
> If you include src/more/Makefile.am into src/Makefile.am (a perfectly
> valid thing to do), you will be unpleasantly surprised that
> src/more/Makefile.am has to actually know where it is in the source
> tree. It needs lines like this:
>
> prog_SOURCES += more/file3.c more/file4.c
>
> and **NOT** this:
>
> prog_SOURCES += file3.c file4.c
>
>
> It's really annoying. It means that renaming a directory is reaaly hard.
You can reduce the pain by using variables:
more = more
prog_SOURCES += ${more}/file3.c ${more}/file4.c
so that a rename now only has to touch the 'more =' line, rather than
every use.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Conditional AC_DEFINE with m4_define variable?
[adding autoconf, as this question technically is independent of automake] On 12/22/2012 07:52 AM, Jef Driesen wrote: > Hi, > > When I set a variable with: > > m4_define([dc_version_suffix],[devel]) > > or leave it empty: > > m4_define([dc_version_suffix],[]) > > And then try to conditionally call AC_DEFINE based on whether the > dc_version_suffix is set or not, this doesn't work: > > AS_IF([test "x$dc_version_suffix" = "xdevel"], [ >AC_DEFINE(ENABLE_PTY, [1], [Enable pseudo terminal support.]) > ]) This will expand to either: test "x$" = "xdevel" or test "x$devel" = "xdevel" based on the macro value. Probably not what you wanted. > > However if I use m4_isset, then it does kind of work, except that the > USE_REVISION macro in the config.h is either defined, or not present at > all. > > m4_ifset([dc_version_suffix],[ >AC_DEFINE(USE_REVISION, [1], [Use the revision number.]) > ]) Indeed, this actually does what _I_ would want - since dc_version_suffix is known at m4 time, we might as well use that information to generate the smallest possible configure. But if you _insist_ on delaying the decision until shell time, even though the condition being tested is known at m4 time, then you probably want to use something like this: AS_IF([test "x]dc_version_suffix[" = "xdevel"], [ AC_DEFINE([USE_REVISION], [1], [Use the revision number.]) ]) which expands the literal contents of the macro in place, so that your configure will then either contain: test "x" = "xdevel" or test "xdevel" = "xdevel" Or, if you _want_ a shell variable rather than an m4 variable as the source of your decision, then be sure you set up that shell variable: [dc_version_suffix]=dc_version_suffix AS_IF([[test "x$dc_version_suffix" = "xdevel"]], [ AC_DEFINE([USE_REVISION], [1], [Use the revision number.]) ]) where the extra quoting is necessary to ensure that your configure file will look like either: dc_version_suffix= test "x$dc_version_suffix" = "xdevel" or dc_version_suffix=devel test "x$dc_version_suffix" = "xdevel" Using a different shell variable name than the m4 macro name will make it easier to type, without quite so much quoting: version_suffix=dc_version_suffix AS_IF([test "x$version_suffix" = "xdevel"], [ AC_DEFINE([USE_REVISION], [1], [Use the revision number.]) ]) > > Does anyone know how to implement this correctly? It really depends on what you are trying to accomplish by deciding something at m4 time, but deferring the action on that decision until configure time. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
On 02/01/2013 05:00 PM, Peter Rosin wrote: > > And in fact, I just expressed how I think removing support for > INCLUDES is wrong, for *both* projects! I agree that removing it from automake is counterproductive. But I support removing it from Automake-NG - as long as we are moving to a newer environment, we can afford to modernize and get rid of namespace pollution. > but supporting INCLUDES will never hinder progress (I > fail to see how anyway). Namespace cleanliness in Automake-NG is a nice goal, one where it is worth warning about (but not removing) use of INCLUDES in Automake in order to make it easier to switch to Automake-NG. It may turn out that in Automake-NG, supporting INCLUDES costs a lot more clutter than desirable. Remember, in Automake-NG, we use GNU make features, such as the ability to easily iterate over all targets that match a certain glob pattern - but this only works if a pattern is easy to write. It is easy to glob for all things beginning with AM_, but harder if you have to special-case for outliers like INCLUDES. > To me, the change was made just because > it was perceived as messy or redundant. But the messiest part > of the removed code was the deprecation warning. Carrying on > with the support for INCLUDES in automake costs nearly nothing. I agree that _in automake_, carrying support for INCLUDES costs almost nothing, since we already have code to detect INCLUDES, and since we already have to issue warnings about using INCLUDES. > Supporting INCLUDES in automake-NG costs nearly nothing. This, however, is a statement I'm not willing to concede; so while I agree with the decision to deprecate (but not remove) INCLUDES from automake, I think it is fair game to state that someone switching to Automake-NG should be prepared to avoid INCLUDES, as part of that switch. > > All in my humble opinion, of source. Errm, of course. Same goes for me :) > > Cheers, > Peter > > PS. Keep up the good work. Likewise, I applaud your efforts on both automake and Automake-NG, and hope that we can get automake stable enough that you can spend some fun time with Automake-NG. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
On 02/02/2013 01:40 AM, Stefano Lattarini wrote: >> I subscribe to all the good opinions about NG that have been >> made here. I would definitely use it once there is a release >> (I have already been criticized several times for having used >> then-CVS versions of the Autotools in Bison, and I don't want >> to go in that direction again). >> > Oh, but I wasn't suggesting to use Automake-NG to bootstrap an official > GNU package! Why not? The end product tarball will require GNU make, but other than that, the end user won't care whether automake or Automake-NG was used to create the tarball. Besides, it is already possible to use automake in a manner that requires GNU make, so end users of those packages won't notice a difference. I guess where it might matter is if distros try to rerun Automake-NG as aggressively as they try to rerun automake on existing packages. Existing distros have stacked the autotools so that they can rerun the same version of automake as a package was originally built with, even if a newer automake has been released since then. So if Automake-NG releases are breaking backwards compatibility for the first little while due to being at alpha quality, that implies that distros will have to repeat their efforts on providing a stacked Automake-NG release for any cases where a package needs to be re-autotooled as part of the distro process. On the other hand, most of the cases where distros end up relying on stacked automake is for packages that aren't actively maintained upstream, and therefore need to have their configure.ac and Makefile.am patched downstream. It can be assumed that the early adopters of Automake-NG are still active, and will be released frequently enough, that it will be easier to fix issues upstream and re-release than to make the distros have to carry downstream patches against configure.ac and Makefile.am that require rerunning the autotools as part of the distro process. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Autoreconf stops with "non-POSIX variable name"
[adding automake] On 03/29/2013 03:44 PM, Russ Allbery wrote: >> MY_REVISION_FILE=my-revision.txt >> MY_REVISION=$(shell cat $(top_srcdir)/$(MY_REVISION_FILE)) $(shell ...) is a GNU make extension, and by using it, you are making your Makefile.am useless for all other make flavors. Automake's goal is to be portable to ALL makes by default, hence the warning. > >> server/Makefile.am:9: cat $(top_srcdir: non-POSIX variable name >> server/Makefile.am:9: (probably a GNU make extension) >> autoreconf: automake failed with exit status: 1 Admittedly, the warning is rather poor quality; perhaps it is worth turning this into an automake bug to improve the quality of that message. > > This is actually an Automake question, but the short answer is that you > probably have fatal warnings enabled and you need to add -Wno-portability > to the Automake flags (in AM_INIT_AUTOMAKE, for example). Or don't use $(shell), or upgrade to Automake-NG (which _requires_ GNU make to be installed on the end-user's machine, and therefore should let you use GNU make extensions without question). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Autoreconf stops with "non-POSIX variable name"
On 04/01/2013 05:07 PM, Borchert, Oliver wrote: > Eric and Russ, > > thanks for the reply. After long testing back and forth I decided to use > AC_SUBST. > My solution might not be the cleanest but it works for me. It may work for you, but it alienates all users that were previously able to build your package with non-GNU make. (Are there any?) > > In configure.ac I added the following line > AC_SUBST([DOLLAR_SIGN],[$]) > > In the Makefile.am I changed my previous line into > MY_REVISION=@DOLLAR_SIGN@(shell cat $(SRC_DIR)/$(MY_REVISION_FILE)) If you care about non-GNU make users, then you can't use $(shell). And as long as you are going to mandate that your package be built with GNU make, then you might as well go all the way and document that fact in your README file, as well as: >>> This is actually an Automake question, but the short answer is that >>> you probably have fatal warnings enabled and you need to add >>> -Wno-portability to the Automake flags (in AM_INIT_AUTOMAKE, for >> example). ...tell automake that you don't care about the non-portability aspect by adding -Wno-portability to your AM_INIT_AUTOMAKE, at which point you'd no longer need your @DOLLAR_SIGN@ hack. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: $(OBJEXT) equivalent for .lo files?
On 04/16/2013 07:55 AM, Rhys Ulerich wrote: > Hi all, > > Explicit dependencies look like > foo.$(OBJEXT) : $(srcdir)/foo.F90 bar.$(OBJEXT) > where $(OBJEXT) serves to insulate one from whether or not the suffix > is .o for an object file. $(OBJEXT) is .o on Unixy systems, but .obj on some other platforms. > > What's the $(OBJEXT) equivalent for a .lo file? I'm providing > explicit dependencies for some Fortran files and need to express > things like > foo.lo : $(srcdir)/foo.F90 bar.lo > > Or, is the .lo extension guaranteed across platforms? .lo, on the other hand, is platform independent, so it needs no variable wrapper. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Put GNU build system files in a subdirectory?
On 04/24/2013 06:44 PM, Andy Tai wrote: > The GNU Build system is generally set up such that the Makefile.am, > configure.ac, etc. files are in the root directory of a software project. > Is there a way to place these files in a subdirectory of the root > directory, like this as an example: > > ./ > README > COPYING > GNUBuild/ > Makefile.am > configure > ... > include/ > src/ > > ... > > > This may mean the user has to run configure from the subdirectory GNUBuild > as the initial step. But the good thing is that this makes the source > files and build files separate and allows co-existence of different build > system support.. for example, CMake's CMakefile.txt can coexist with GNU > build files in a clean fashion Sounds like you are asking a similar question to this: https://lists.gnu.org/archive/html/automake/2013-04/msg00014.html with this answer of no (which really means: if YOU write the patches and prove that they are worth maintaining, then it could be added in the future, but no one else is interested in this unusual setup): https://lists.gnu.org/archive/html/automake/2013-04/msg00021.html -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Setting python interpreter in scripts
On 07/31/2013 03:23 PM, Adam Mercer wrote: > Hi > > In one of our projects we have several python scripts that we need to > ensure that the python interpreter is set to the one found by > configure. At the moment we are doing this by having the interpreter > set to @PYTHONPROG@ and then using the following rule: > > python_config.sed: > @-rm -f python_config.sed > @echo "s+@PYTHONPROG@+@PYTHON@+g" >> python_config.sed This is an unsafe sed script, if configure found a version of PYTHON that includes a '+' in its (possibly absolute) name. Better would be using something that has to be quoted for use in the shell, as that is less likely to be the name of any PYTHON directory the user desires to use, as in 's|@PYTHONPROG@|@PYTHON@|'. > > script: $(srcdir)/script.in python_config.sed > $(AM_V_GEN)sed -f python_config.sed $(srcdir)/script.in > script > @chmod +x script > > This has always seemed like an ugly hack to me, especially as the > script is in the VCS as script.in instead of the actual name. > > Can anyone offer any more sane ways of accomplishing this? Why not add this to your configure.ac: AC_SUBST([PYTHON], ...) AC_CONFIG_FILES([script], [chmod +x script]) prior to the AC_OUTPUT, so that running config.status (as part of the configure script itself) will automatically replace @PYTHON@ from the script.in template into the output script without you repeating the work in your makefile. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: autotest, automake & non-recursive makes
On 09/26/2013 10:16 AM, Diab Jerius wrote: > I embarked on a journey yesterday involving automake, autotest, and > non-recursive makes. I started with the example Makefile.am snippet > provided in the autoconf (v 2.69) manual and ran into a few problems, > which I've kludged around. Perhaps others have better solutions? And when you do come to consensus on the best solution, please also send a patch to the autoconf list so that they can update their manual to include it as an example. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: autotest, automake & non-recursive makes
On 09/26/2013 12:13 PM, Diab Jerius wrote: > On Thu, Sep 26, 2013 at 2:09 PM, Eric Blake wrote: >> On 09/26/2013 10:16 AM, Diab Jerius wrote: >>> I embarked on a journey yesterday involving automake, autotest, and >>> non-recursive makes. I started with the example Makefile.am snippet >>> provided in the autoconf (v 2.69) manual and ran into a few problems, >>> which I've kludged around. Perhaps others have better solutions? >> >> And when you do come to consensus on the best solution, please also send >> a patch to the autoconf list so that they can update their manual to >> include it as an example. > > > Will do. This seemed a more appropriate starting place for the discussion. Agreed, since it relies on brand-new automake features :) -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: please confirm license for Automake
On 04/08/2014 01:21 AM, Kovacs, Mariann wrote: > Dear All, > > Please confirm under which GNU license Automake is licensed. Which version of automake are you interested in? It looks like the current git tree is still stuck at GPLv2+, although, from commit fcf2f56, we intend to eventually move to GPLv3+ plus exception (the exception ensuring that you can use automake on a non-GPL project or on a GPLv2[+] project without being forced to use GPLv3), similar to what autoconf has already done. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Produce symlink into builddir on VPATH?
On 06/11/2014 04:18 PM, Rhys Ulerich wrote: > Other than resorting to the shell in a target, is there a way to cause > Automake to produce a symlink from the source tree into the build tree > if-and-only-if the build is VPATH? Yes, for new enough autotools. See how gnulib does it for GNUmakefile: http://git.savannah.gnu.org/cgit/gnulib.git/tree/modules/gnumakefile -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: What would the correct way be to handle a program with a PID file being built to a prefix directory?
On 06/18/2014 08:19 AM, Gavin Smith wrote:
> On Wed, Jun 18, 2014 at 3:47 AM, Michael Lueck
> wrote:
>> Prefix, building the program with non root permissions to be run in the
>> context of a user's home directory.
>>
>> PID file, generally defaults to /var/run, however in this case permissions
>> are not granted to /var/run. One could assume ~/var/run would be the proper
>> place for the PID file.
>>
>> Building a certain OSS/FS app fails when being built with a prefix
>> specified, as /var/run is still assumed for the PID file. I hacked the
>> source code to obtain ability to target ~/var/run for the PID file, and the
>> program works as expected.
>>
> It depends on the build system of the program in question, but it
> looks like "localstatedir" is the preferred makefile variable for this
> directory, and is as an autoconf output variable. It should be set
> automatically from whatever "prefix" directory was specified.
Actually, autoconf 2.70 (if I ever get time to release it) supports a
new --runstatedir option, which defaults to ${localstatedir}/run; but it
should be preferred over direct use of $localstatedir because some
distros want to stick --runstatedir at /run in stead of /var/run.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Portable Use of Variables
On 10/27/2014 11:11 AM, Nick Bowler wrote: > On 2014-10-26 22:15 +0200, fr33domlover wrote: >> I'm a bit confused about all the expressive features and ways to use makefile >> variables, so just to be sure - >> >> http://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html >> >> Are these uses of variables portable, or should a portable Makefile.am use >> only >> the plain $(var) form without the tricks? > > The first form of expansion on that page, $(var:.a=.b), should be OK. > They are standard in POSIX and work on all make implementations that I > know of. > > The version with % characters is not portable. That said, POSIX is hoping to standardize it in the next few years: http://austingroupbugs.net/view.php?id=519 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?
On 10/29/2014 04:29 PM, Diego Elio Pettenò wrote: [we tend to avoid top-posting on technical lists] > Can't we just say that gnu-flavour automake is pointless and foreign should > be the default? Or am I too opinionated on that? For GNU projects, the 'gnu' flavor still makes sense, even if it could use a little modernization such as easier automation of generating ChangeLog from version control. And while these days, automake is probably used by more non-gnu projects (where 'foreign' may make more sense) than GNU projects, that's still not a good reason to toggle the default. I like what the GNU Coding Standards represent, and deviating from them deserves a mention in configure.ac to make it apparent that you thought about it. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Portable Use of Variables
On 11/11/2014 10:59 AM, fr33domlover wrote: >>> The first form of expansion on that page, $(var:.a=.b), should be OK. >>> They are standard in POSIX and work on all make implementations that I >>> know of. >>> >>> The version with % characters is not portable. >> >> That said, POSIX is hoping to standardize it in the next few years: >> >> http://austingroupbugs.net/view.php?id=519 >> > > Hmmm I was sure it's portable because `make distcheck` doesn't complain about > the %s, and I'm using -Werror and -Wall automake flags. How bad is it? I > suppose it's not specific to just GNU make alone? automake can't warn about all non-portable aspects, although patches to make it warn about more cases would be welcome. And the fact that POSIX is planning to standardize % substitutions in make is a sign that existing implementations that already support it are in agreement (more than just GNU make), so if you want to be on the leading edge of the curve, you aren't excluding that many users. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Using 'make dist' with a 32 UID
On 01/05/2015 10:30 AM, Finucane, Stephen wrote:
>> On 01/05/2015 03:08 AM, Finucane, Stephen wrote:
>>> Autotools defaults to the 'v7' legacy tar format in GNU tar, through
>> passing of the '-o' parameter to GNU tar. Enabling this option results in
>> errors for users with 32 bit UIDs. For example, with the Open vSwitch
>> package:
>>
>> 'make dist' is under the purview of automake, not autoconf. You may get
>> a better response by involving the automake list.
>
> Sorry - I find the line between the two to be rather blurred at the best of
> times :) Should I forward this or CC this list?
I've added the automake list in cc (I'm interested enough in the outcome
that I don't mind if the autoconf list remains in the distribution).
>
>>
>>>
>>> $ make dist
>>> ...
>>> tardir=openvswitch-2.3.90 && ${TAR-tar} chof - "$tardir" | GZIP=--
>> best gzip -c >openvswitch-2.3.90.tar.gz
>>> tar: value 12345678 out of uid_t range 0..2097151
>>> tar: Exiting with failure status due to previous errors
>>> make[1]: Leaving directory `/development/ovs'
>>> ...
>>>
>>> I managed to modify the Autoconf 'configure.ac' file to use the 'tar-
>> ustar' format, which allow longer file names and other niceties. Again,
>> with the Open vSwitch package:
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index ebb8b02..6505189 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -19,7 +19,7 @@ AC_CONFIG_MACRO_DIR([m4])
>>> AC_CONFIG_AUX_DIR([build-aux])
>>> AC_CONFIG_HEADERS([config.h])
>>> AC_CONFIG_TESTDIR([tests])
>>> -AM_INIT_AUTOMAKE
>>> +AM_INIT_AUTOMAKE([tar-ustar])
>>
>> Are you proposing that we change the way autoconf is distributed? That
>> won't affect any other packages (you'd have to make the same patch for
>> each affected package), and so far, your code shows that you had
>> problems in building an openvswitch tarball, not an autoconf tarball.
>> Again, changing automake to do this automatically for ALL packages (once
>> those packages are built with a new enough automake) rather than trying
>> to patch one configure.ac for every affected package, seems like it
>> would be the better course of action.
>>
>> I'm still open to be convinced that autoconf needs to alter its own
>> configure.ac, but I don't have enough evidence yet that it would make a
>> difference.
>
> Not necessarily. The use of the 'v7' format means any users with a 32 bit UID
> will need to modify every 'configure.ac' file they come across to fix the
> above issue. However, it's not like I personally work with enough packages to
> make this much of an issue. Instead, an approach that would allow me to
> enable the 'tar-ustar' format dynamically (like the 'configure' option above)
> would be just fine, if such a thing exists. This would allow me (and all
> 32bit UID users) to adopt a standard approach to working with Autotools based
> packages (i.e. always pass an option to the 'configure' script of any
> Autotools-based package).
>
> Changing the default tar format used by Autotools would result in a permanent
> fix for all affected users, as you say (affected users = the other developers
> in my team in Intel, for example). However, I don't know if this would cause
> compatibility issues on certain (very, very old) machines. You could see a
> scenario whereby the 'make dist' target of (previously working)
> autogenerated-Makefiles files would break when Autotools is updated, due to
> the ustar format not being supported. I have no data on tar ustar support,
> I'm afraid.
As for whether the upstream automake should make it easier for runtime
overrides of the format, or even dynamic changes, I am not sure. I also
know that some packages (particularly those using gnulib's GNUmakefile)
explicitly set:
export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
to try and avoid the problem of a 32-bit uid interfering with the
creation of old-style tar files. Maybe that is an approach that should
be folded into automake?
>
> I will attempt to reproduce this issue on other Autotools-based packages and
> report my findings.
>
Not sure that your additional testing will change anything - again, the
issue here is that automake would be the one place to change for
everyone else to automatically benefit from, once packages are rebuilt
with newer automake.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: how should package config files be installed
On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: > I want to distribute the correct *.pc files with the libraries I'm building. > While it's a simple matter to find the format of this file (by examining > existing ones or online), I'd like to know if there's a preferred procedure > for generating these files. What should be done in order to make this work? .pc files are created by the pkg-config tool. More details on their web site: http://www.freedesktop.org/wiki/Software/pkg-config/ -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: how should package config files be installed
On 03/31/2015 02:26 PM, Roman Neuhauser wrote: > # ebl...@redhat.com / 2015-03-31 11:40:52 -0600: >> On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: >>> I want to distribute the correct *.pc files with the libraries I'm >>> building. While it's a simple matter to find the format of this >>> file (by examining existing ones or online), I'd like to know if >>> there's a preferred procedure for generating these files. What >>> should be done in order to make this work? >> >> .pc files are created by the pkg-config tool. More details on their web >> site: http://www.freedesktop.org/wiki/Software/pkg-config/ > > i can't find any support for this claim anywhere in that "web site" > (it's a short page). can you be more specific? It's a different project that automake, so you'll probably get better support on the pkg-config mailing list than you will here. But the page I linked to above includes a link to their FAQ: http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq which goes into more details. I have not personally converted a project over to using pkg-config, so I can't provide any better details than "read the manual". -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Question on AM_TAP_AWK
On 04/07/2015 03:30 PM, Arthur Schwarz wrote: > > TEST_LOG_DRIVER = env AM_TAP_AWK='$(AWK)' $(SHELL) \ > $(top_srcdir)/build-aux/tap-driver.sh > > AM_TAP_AWK is defined right there, in the example code. Its purpose is > to tell the tap-driver.sh program which AWK program to use. > > [1] > https://gnu.org/software/automake/manual/automake.html#Use-TAP-with-the-Auto > make-test-harness > > Cheers, > -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) Hey [Your mail client has the horrible habit of breaking threading, as well as doing poor quoting of the text you are responding to. Then the fact that you stuck your entire reply after a '-- ' separator meant that sane mail clients treat your entire content as part of a signature, which means it gets truncated by default; the only way I could reply to your text was to select the entire message before replying, but that in turn triggers a "feature" in my mail client that loses all line breaks in the signature, making this harder to read] > thanks; I guess what your saying is that the variable needs no > definition; it's self-defining. Does this mean that the TAP interface > needs this variable only under some circumstances but not under all? If I understand correctly, you only need to set AM_TAP_AWK in your makefile if you want to allow the user to select a different awk than what a PATH search would normally find, as that is what tap-driver.sh does when the variable is not set. > Since it is self-defined within an example and not in some text which > defines the TAP interface I suppose that it is only required sometimes, > otherwise the TAP interface would have it as part of its description. > I'm also a bit confused about the use of env. Does this use mean that > Makefile evaluates TEST_LOG_DRIVER by escaping to a shell? Otherwise, > does Makefile do it's own interpretation of 'env'? the reason that I'm > asking this question is that on env Cygwin (8.23-4) manual page (and env > --help) shows: SYNOPSIS env [OPTION]... [-] [NAME=VALUE]... [COMMAND > [ARG]...] which seems to imply that either we have NAME=VALUE or NAME=. > The example shows $(SHELL) which has neither of these. I suppose that The example shows that you are executing $(SHELL) as the COMMAND, with the environment variable AM_TAP_AWK pre-set to a value. The use of 'env' allows use with makefiles that default to executing some other shell than 'sh' (most likely to be the case on windows systems, but non-standard behavior since POSIX standardized make to always use sh). > when $(SHELL) is evaluated it produces some variable name (?) but if it > does, how does TAP determine what this name is from the environment? It produces a command name, not a variable name (namely, the command is the shell to use for interpreting the shell script). > Does it search the environment for a fixed set of names and then assume > success at the first one found? Can I supply TAP with a shell whose name > is not one of the fixed set of names? Anyhow, I'm abandoning TAP and > going to try to use the Custom Drivers and hope that if the definitions > are not clearer then at least I can get some sort of test going. If that > doesn't work then I will distribute my software with no testing. Thanks > art The failure of the past is the challenge of the present and the > success of the future. > -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you echo a shell variable reference
On 04/13/2015 04:24 PM, Arthur Schwarz wrote:
>
> I am trying to echo:
>echo 'exit $status' >> file
>
> from the Makefile generated by Makefile.am. What I get is:
>echo 'exit $status' >> file
>
> in the Makefile, which is correct, but in execution (make check) I get
>exit tatus
>
> in file. I have tried variations of $status to no avail. Any idea how I can
> get the correct result in file?
The same as any other time you want a literal $ to be passed through to
the shell when writing Makefile snippets: escape the $ with another $,
so that 'make' won't try to treat it as an expansion of ${s} at make time:
foo:
echo 'exit $$status' >> file
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
Re: How do you set VERBOSE for parallel testin
On 05/07/2015 03:42 PM, Arthur Schwarz wrote: > I'm trying to set VERBOSE in a parallel test setup and it doesn't seem to > work. I've used: > VERBOSE = yesand > VERBOSE = 1 Where were you making that setting, in Makefile.am? > > But I get the normal output listing. The Automake manual (Section 15.2.3 > Parallel Test Harness) says: " The output from failed tests is collected in > the test-suite.log file. If the variable 'VERBOSE' is set, this file is > output after the summary." It works for me when I do: make check VERBOSE=1 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you set VERBOSE for parallel testin
On 05/08/2015 04:55 PM, Arthur Schwarz wrote: > > I just checked the latest iteration of my output listing (VERBOSE = 1) and > saw the rule for > Makefile:478 showing test-suite.log failed. Don't know why. > If any test causes a FAIL, XPASS, or ERROR condition, then 'make check' will likewise fail. The output from make is telling you that your testsuite caught failures that should not be present if the testsuite were passing. > The output listing is below and the Makefile.am is included in an > attachment. > > Heck, I don't know what I'm doing. If anyone can explain what I need to do > to remove the error messages I'd really appreciate it. Which error messages are you trying to remove? The only error message I say in the output you posted is expected, given that you have a failing test. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you set VERBOSE for parallel testin
On 05/08/2015 05:13 PM, Arthur Schwarz wrote: >> >> >> On 05/08/2015 04:55 PM, Arthur Schwarz wrote: >>> >>> I just checked the latest iteration of my output listing (VERBOSE = 1) > and >>> saw the rule for >>> Makefile:478 showing test-suite.log failed. Don't know why. >>> >> >> If any test causes a FAIL, XPASS, or ERROR condition, then 'make check' >> will likewise fail. The output from make is telling you that your >> testsuite caught failures that should not be present if the testsuite >> were passing. > > My issue is that the output indicates that the rule for test-suite.log > fails. Is this expected? My thought (from the automake manual) is that even > if there is a failure there should be no difficulty creating or outputting > test-suite.log. The test harness created a test-suite.log (included as an > attachment) but failed to output it. Don't know why. Yes, this is expected. test-suite.log is created no matter what, but the rules associated with creating it fail if the log contains any failure reports, so that make will quit running and let you investigate those failures. As for why test-suite.log was not replayed as part of the make output, I'm not sure that you had VERBOSE=1 set. So far, you've only attached the generated Makefile (but not the source Makefile.am), and didn't show what command you ran. You'll need to make your setup easier for others to reproduce before we can see what you are attempting. As for the test-suite.log not having much output, it is probably because your tests are not very noisy. Running make captured all of the output of your tests, but if your tests didn't output anything, then the log has very little to show. Again, without knowing what your test scripts are doing, it's hard to reproduce your setup. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you set VERBOSE for parallel testin
On 05/14/2015 08:29 PM, Peter Johansson wrote: > On 05/15/2015 10:36 AM, Arthur Schwarz wrote: >> And, if I guess correctly, the user can write >> "make check TESTSUITEFLAGS=-jN" > > I've never seen TESTSUITEFLAG before, so I don't know. > TESTSUITEFLAGS is the suggested variable name for someone using the 'autotest' setup from autoconf (which is yet another testing framework, different from automake, where automake runs a single test called 'testsuite', but 'testsuite' itself can run multiple tests in series or parallel). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How can I pass $@ to Makefile?
On 05/28/2015 02:41 PM, Arthur Schwarz wrote: > > So let's try this with your make rule. The lines starting with a > "+" character are the actual commands being executed by the shell: > > % make SHELL='sh -x' test3.abc > echo '#!/bin/bash' > test3.abc > + echo '#!/bin/bash' > echo "echo test3.abc $# ' [' $@ ']'>> test3.log" >> test3.abc This is what make passed to the shell... > + echo 'echo test3.abc 0 '\'' ['\'' '\'']'\''>> test3.log' ...and this is what the shell executed, after doing shell expansions. > echo "echo I am a test script>> test3.log" >> test3.abc > + echo 'echo I am a test script>> test3.log' > > (to get snarky) I saw the problem before. The issue is that the $#/$@ > expands inside make (when test.abc: is executed and not in the shell script. > I can do this if I put the script into the appropriate directory and take > creation out of Makefile.am. I know this. I just wish there was another way. No, $# did NOT expand inside make, but inside the shell that make was running when asked to execute the commands that will create test3.abc. You were not using correct shell quoting. It sounds like you want to defer expansion of $@ not only in make, but also in the shell that make runs. Let's look more closely at your attempt: echo "echo test3.abc $# ' [' $@ ']'>> test3.log" >> test3.abc says to do shell interpolation of $# and $@ inside the double quotes, then append the resulting string to test3.abc. After executing that statement in shell, the last line in test3.abc will be: echo test3.abc 0 ' [' ']'>> test3.log Whereas if you had used different quoting, as in: echo 'echo test3.abc $# " [" $@ "]">> test3.log' >> test3.abc so that you were telling the shell to NOT interpret $, then the last line in test3.abc will be: echo test3.abc $# " [" $@ "]">> test3.log Of course, that is still underquoted, if you intend to avoid globbing/splitting on the results of $@ when executing the file test3.abc. You want the $@ to be inside double quotes. Ultimately, it sounds like you are not quite sure of how many layers of processing text will go through. So let's work backwards: First, figure out what you want in the file test3.abc. Probably something like this (and note that things are a lot easier by avoiding ' in this script): #!/bin/bash echo test3.abc "$# [ $@ ]">> test3.log echo I am a test script >> test3.log Next, figure out how to generate test3.abc using shell scripting (note that I'm using '' quoting here to suppress all expansions in the text being put in the generated file, which is why I avoided ' in the script I am generating): echo '#!/bin/bash' > test3.abc echo 'echo test3.abc "$# [ $@ ]">> test3.log' >> test3.abc echo 'echo I am a test script >> test3.log' >> test3.abc Finally, write that shell script inside a make rule (make passes everything to shell except for $, which is escaped by adding another $): test3.abc: echo '#!/bin/bash' > test3.abc echo 'echo test3.abc "$$# [ $$@ ]">> test3.log' >> test3.abc echo 'echo I am a test script >> test3.log' >> test3.abc Before you can write effective makefile rules for invoking complicated shell scripting, you first need to know the difference between '' and "" in shell quoting rules, and practice writing shell scripts that generate shell scripts to get a feel for using nested layers of quoting when generating files. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: What is minimum set of Automake work files needed for distribution on github?
On 09/28/2015 04:20 AM, Robert Parker wrote: > I need to meet the requirements of 2 sets of users, the ordinary user who > is only interested `./configure; make; make install` and the power users > who want to start with `autoreconf`. > > So far google search on the topic has only increased my confusion. The most common solution: don't store anything but configure.ac and Makefile.am in git. The power user checks out git, and runs 'autoreconf' to bootstrap the project, then runs 'make dist' to create a self-contained tarball. The ordinary user takes a tarball, unpacks it, and runs './configure; make; make install' without needing any autotools installed. Ordinary users therefore do NOT use direct git checkouts. Working with git is reserved for power users. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: method for altering installation location
On 11/13/2015 12:11 PM, Andy Falanga (afalanga) wrote:
> How does one properly make a build system install to the
> system-preferred locations for 64-bit binaries? I'm wondering how to
> properly make my build system choose "/usr/lib64" over simply "/usr/lib"
> when configure is run. I know this can be done simply via
> "--prefix=/usr --libdir=lib64", and maybe this is what it should be
Yes, that IS the preferred way (although autoconf's config.site can make
it easier). Your configure script should not hard code any knowledge,
rather the user of your configure script should supply their knowledge.
It's also recommended that you convince your distro to install a
/usr/share/config.site file, which is the easiest way to get
'./configure --prefix=/usr' to just do the right things for all the
other variables. Fedora has already done so:
$ rpm -qf /usr/share/config.site
autoconf-2.69-20.fc22.noarch
$ cat /usr/share/config.site
# This is the config.site file to satisfy FHS defaults when installing below
# /usr.
#
# You may override this file by your config.site using the CONFIG_SITE env
# variable.
#
# Note: This file includes also RHEL/Fedora fix for installing libraries
into
# "/lib/lib64" on 64bit systems.
if test -n "$host"; then
# skip when cross-compiling
return 0
fi
if test "$prefix" = /usr \
|| { test "$prefix" = NONE && test "$ac_default_prefix" = /usr ; }
then
test "$sysconfdir" = '${prefix}/etc' && sysconfdir=/etc
test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
test "$localstatedir" = '${prefix}/var' && localstatedir=/var
ARCH=`uname -m`
for i in x86_64 ppc64 s390x aarch64; do
if test $ARCH = $i; then
test "$libdir" = '${exec_prefix}/lib' &&
libdir='${exec_prefix}/lib64'
break
fi
done
fi
> (along with some type of bootstrap script). I was just wondering if
> there are already elegant/"smiled upon" methods for doing this in
> configure (i.e. configure.ac).
There's nothing for you to do in configure.ac (that doesn't scale -
you'd have to modify every packages' configure.ac to get them to all act
the same). Rather, the work should be done by whoever wants
installation of things into /usr to just work.
See also the autoconf manual:
https://www.gnu.org/software/autoconf/manual/autoconf.html#Site-Defaults
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: aclocal using automake Automake::XFile
[not really an m4 problem, so future replies can be to just automake]
On 12/08/2015 02:51 AM, Arkadiusz Miśkiewicz wrote:
>
> Hello.
>
> Using
> m4 (GNU M4) 1.4.17
> automake (GNU automake) 1.15
>
> /usr/bin/aclocal contains code:
>
> $traces .= " --language Autoconf-without-aclocal-m4 ";
> $traces = "echo '$early_m4_code' | $traces - ";
> ...
> verb "running $traces $configure_ac";
>
> my $tracefh = new Automake::XFile ("$traces $configure_ac |");
Can you try 'aclocal --verbose', to get the "running ..." output line
produced just before the failed XFile() creation attempt?
>
> which fails here:
> $ cd libgii-2.2.2; LC_ALL=C aclocal
> aclocal: error: cannot open echo 'm4_define([m4_require_silent_probe], [-])'
> |... --trace='AM_AUTOMAKE_VERSION:$f::$n' configure.ac |: No such file or
> directory
Huh - it sounds like your version of perl is trying to open a literal
file named 'echo ... | autom4te ... autoconf.ac |' , instead of properly
opening a subshell command that feeds echo to autom4te then collects the
output of autom4te (basically, Automake::XFile() is trying to do the
equivalent of a popen() on a shell command).
> Tried small script to reproduce and it also fails:
>
> #!/usr/bin/perl
>
> BEGIN {
> push ( @INC,"/usr/share/automake");
> }
>
> use strict;
>
> use Automake::XFile;
>
> my $traces = "echo 'zupa'";
> my $tracefh = new Automake::XFile ("$traces");
>
> $ LC_ALL=C perl a1.pl
> a1.pl: error: cannot open echo 'zupa': No such file or directory
Not quite the same, if you don't actually have a file named 'zupa'
handy; and particularly since the aclocal usage is trying to use perl's
open("command |") notation, not open("file") notation. Could it also be
a problem with your particular build of perl, or maybe a newer version
of perl has introduced some backwards incompatible change that
autoconf/automake now need to work with?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: More control over 'make dist'
[re-adding Michal; not sure he is a subscriber. It's usually best to reply-to-all rather than assume that all readers are on-list] On 09/14/2016 02:10 PM, Warren Young wrote: > On Sep 14, 2016, at 7:49 AM, Peter Rosin wrote: >> >> On 2016-09-14 11:33, Michal Privoznik wrote: >>> >>> ln -s $xml.in $xml.out >>> >>> However, I was looking into archive produced by 'make dist' the other >>> day and found out that the symlinks are not preserved. >> >> I believe that is for the benefit of supporting unpacking the release >> tarball on systems that do not support symlinks, or where symlinks are >> not as flexible as one might wish for. > > The question, then, is whether libvirt would ever be unpacked on such a > system. > > I’m barely aware of what libvirt does, but I think I can come up with a > plausible scenario: libvirt built from source on Cygwin. > > It appears from the home page that libvirt already supports Hyper-V, so a > naive user might decide to build it under Cygwin rather than whatever native > Windows toolchain is currently used for that case. (The reason being that > libvirt, coming from the Linux world, probably builds better under a > Unix-like environment.) Since NTFS symlinks have a number of unfortunate > limitations[1] and restrictions[2], the tarball almost certainly won’t unpack > correctly. Cygwin unpacks and handles symlinks just fine as one of the many things it emulates, so that's not the issue (note, however, that non-cygwin apps are generally unable to recognize cygwin symlinks, which are intentionally NOT done as NTFS symlinks because NTFS symlinks are not POSIXy). I'd be more worried if trying to unpack libvirt and build it with mingw, where you no longer have cygwin symlinks in the mix, and would indeed be limited to just NTFS symlinks. But I think that mingw ports of tar already take care of that, by turning symlinks in the tarball into file copies (where the link target was also in the tarball) or an error message (where the link target is unknown) (although I haven't actually tested what MSYS would actually do, so I welcome further comments from anyone with experience). And yes, libvirt is (cross-)built for mingw on Fedora already, as well as me getting ready to prepare a Cygwin distribution build of libvirt (both for the remote machine control aspect, and for the HyperV aspect). I'm less familiar with cross-building for mingw to know for certain whether symlinks in tarballs cause problems for mingw targets, or whether Wine emulation on Linux even handles symlinks. So that agrees with the notion of making tarballs as portable as possible by avoiding symlinks. On the other hand, maybe the GNU Coding Standards should be updated to state that avoiding symlinks is no longer required of GNU packages (it's entirely plausible that when automake first coded up the tar -h rule, years ago, there really were Unixy systems where either the file system or the tar program didn't handle symlinks as gracefully as desired, which is a different beast than today's mingw situation). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Words in configure.ac that look like macros forbidden or merely discouraged?
On 06/12/2016 05:25 AM, Gavin Smith wrote: > Hello, Apologies for just now noticing this thread. > > In the Autoconf manual we read: Any reason you mailed this to the automake list, and not autoconf, then? > > > > When you use the same text in a macro argument, you must therefore > have an extra quotation level (since one is stripped away by the macro > substitution). In general, then, it is a good idea to use double > quoting for all literal string arguments, either around just the > problematic portions, or over the entire argument: > > AC_MSG_WARN([[AC_DC] stinks --Iron Maiden]) > AC_MSG_WARN([[AC_DC stinks --Iron Maiden]]) > > > Note what it says: "triggers a warning". However, it seems in some > cases, using a word that looks like it could be a macro triggers a > hard error, not just a warning: > > $ autoreconf -iv > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal > configure.ac:4: warning: macro 'AM_DC' not found in library AM_DC is not the name used in the example, but falls into the namespace reserved by automake, so I guess I see why you are testing it instead of AC_DC. > autoreconf: configure.ac: tracing > autoreconf: configure.ac: not using Libtool > autoreconf: running: /usr/bin/autoconf > configure.ac:4: error: possibly undefined macro: AM_DC > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /usr/bin/autoconf failed with exit status: 1 However, the error message says that it is autoconf (not automake) that is failing, so I don't see how this is applicable to automake. > > Any ideas which it is: is it actually forbidden, or should it be just a > warning? So I guess you are pointing out a documentation error in the autoconf manual, and that the manual should call it an error, not a warning? Sure, I can do that. > > I intend to put information about this here: > http://buildsystem-manual.sourceforge.net/Macro-name-quoting.html#Macro-name-quoting > , which I've adapted from the test in the automake manual. > > Contents of files: > > $ cat configure.ac > AC_INIT([helloprog], [1.0]) > AM_INIT_AUTOMAKE > > echo AM_DC rocks > > AC_CONFIG_FILES([Makefile]) > AC_OUTPUT > $ cat Makefile.am > AUTOMAKE_OPTIONS=foreign dist-xz > $ > > -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Defining data files to install
On 01/26/2017 03:22 PM, Julie Marchant wrote: > Hi, > > I'm a little confused about how to set up Autoconf to install data files > for the program to use later, and I wondered if someone can clear up my > confusion. > > For reference, the pertinent program is Project: Starfighter: > > http://starfighter.nongnu.org > > Starfighter has a few different directories with required data files: > "data", "gfx", "music", and "sound". All files in these directories need > to be installed to a location that gets defined as DATADIR. From what I > understand so far, the directory I want to use is the one stored in the > pkgdatadir variable, and I include files to install there by assigning > them in a Makefile.am to pkgdata_DATA. But listing the files out from a > Makefile.am in the same directory doesn't copy the directory structure, > and if I indicate a directory from the top-level Makefile.am, "make > install" just ignores (or rather, "omits") it and then spits out an > error with no accompanying information. Makefile.am is read by automake, so your question is more likely to be answered in the automake manual than the autoconf manual. > > What am I missing here? How can I install these data files not into the > top-level pkgdatadir, but in the respective appropriate sub-directories > of pkgdatadir (e.g. "$(pkgdatadir)/data" and "$(pkgdatadir)/music")? I > can't find any documentation on how to do this anywhere. Automake lets you define new targets that are subdirectories. In fact, a quick search for $(pkgdatadir) found an example that might be pertinent to your use case: https://www.gnu.org/software/automake/manual/automake.html#Alternative But I'm not as good at automake as I am at autoconf, so I'm cc'ing that list in, in case someone else has more ideas. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Warning - non-POSIX variable name
On 08/09/2017 12:02 PM, Warren Young wrote: > On Aug 9, 2017, at 9:00 AM, Bob Friesenhahn > wrote: >> >> Passing a relative path to CC seems error prone since it only applies to the >> current working directory and will fail as soon as any Makefile recurses. > > Maybe you have a better answer to this related question: is there a portable > alternative to GNU readlink’s -f option? > > On a Linux box, I’d get around the problem you raise with: > > $ ./configure CC=$(readlink -f > ../../llvm-arm-toolchain-ship/3.8/bin/clang) Why not just: ./configure CC="$PWD/../../llvm-arm-toolchain-ship/3.8/bin/clang" which turns your relative name into an absolute one? Do you HAVE to have the canonical name? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Which files to distribute?
On 01/29/2018 08:11 PM, Victor Porton wrote: > Which of the following files should be uploaded to Git? It depends. Do you want git to track generated files, at the risk of different installed autotools versions creating spurious diffs in those generated files? I don't personally recommend that, but some people like to have their git repo usable even by someone that does not have the autotools installed. Or do you want to require someone checking out the git repo to have tools installed on their machine that the end user client of a tarball does not have to have? > > aclocal.m4 Generated. > autogen.sh Not necessarily the best name (since there is an unrelated GNU Autogen project); some projects prefer the name bootstrap for this sort of script instead of autogen.sh. At any rate, this script is NOT generated by the autotools, so you probably need to check it into git (especially if its goal is to run the autotools to bring a git checkout into a state that you can then run the usual ./configure && make). > compile > config.guess > config.sub > configure > depcomp All generated. > INSTALL If you don't check this in, then you get the default version generated that talks about GNU standards. Which may be fine for your project, or it may be inaccurate; if you check in your own version, automake will leave your version intact. > install-sh > libtool > ltmain.sh > missing All Generated. So of those, I'd only check in autogen.sh (and consider renaming it). However, your subject line said "Which files to distribute", not "Which files to store in version control". The answer there is "All of them" - and automake will automatically distribute all of those files in a tarball when you do 'make dist' (and you can run 'make distcheck' to make sure your tarball is self-contained). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: automake compile problems
On 05/30/2018 04:07 AM, Andy Armstrong wrote: Hi all, I want to compile version 1.16 of automake. On which system? I run ./configure, which creates the Makefile. I run 'make' which results in the following: automake-1.16: >make make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/get-sysconf.sh] in target list That's not GNU make. What version and vendor of make is it? It may mean that automake has regressed, and is no longer outputting makefiles that are portable to your specific make binary. But that's just a warning. Is there an actual failure? make: Makefile: line 3189: Warning -- FSUM9433 Duplicate entry [lib/ylwrap] in prerequisite list @rm -f ./m4/amversion.m4-t ./m4/amversion.m4 make: Error -- @rm: EDC5129I No such file or directory. FSUM8226 make: Error code -1 Okay, that's an actual failure, but it's not obvious on what the context is that might have caused it. Is there an earlier version of automake that built on your platform? Does using GNU make instead of your vendor's default make let you get further? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
On 05/30/2018 11:12 AM, Andy Armstrong wrote: To give some context to what I am doing, here is the timeline: I did have Automake version 1.10, but my ultimate goal here is to compile the nano text editor, which requires at least automake 1.15 and autoconf 2.69. That's if you are modifying the source files and actually developing nano on your mainframe. But what's wrong with the (often simpler) approach of using a more typical development box, probably using GNU/Linux, with modern autotools already installed, and running 'make dist' on the nano package there, then copying the tarball over? Once you've done that, './configure && make' should work without requiring either automake or autoconf installed on the mainframe. After all, the point of the autotools is to build self-contained tarballs that no longer require the presence of the autotools. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
On 05/30/2018 02:23 PM, Andy Armstrong wrote: Hi Eric, [top-posting is a bit harder to read on a technical list, so I'll stick with the easier-to-read inline posting] That could well be a far better approach. I am not sure how to perform cross platform builds, especially taking into account the interesting platform uniqueness such as codepage etc. I'm not proposing cross-building (which is indeed a possibility, but a much more technically challenging one to get correct, so it's never my first suggestion), so much as having two machines: - development machine: has autotools installed, has nano.git [https://git.savannah.gnu.org/cgit/nano.git] checked out (or however you are currently trying to build the latest nano); probably GNU/Linux, and most likely using ASCII encoding - build machine: your mainframe with EBCDIC encoding On the development machine, run all of the prep steps, including any required 'autoconf' and 'automake' steps, prior to './configure && make dist', which creates nano-$vers.tar.$suff (where $suff is typically .gz or .xz, depending on what compression the developers liked) Then copy nano-*tar* file to the build machine (whether by ftp, or by a shared network drive, or by whatever other means you have at your disposal) Then on the build machine, unpack the tarball (perhaps involving some dd invocations to transliterate from ASCII to EBCDIC as needed - but do so in a manner which preserves timestamps - I honestly don't know what steps are required in transferring an ASCII-encoded tarball into use on an EBCDIC machine) Now, on the build machine, you only have to type './configure && make'; you don't have to run autoconf or automake (well, as long as you didn't mess up timestamps such that make thinks configure.ac is newer than configure, or some similar spurious change in dependency). In fact, the parts about the development machine have often already taken place without requiring you to anything: https://ftp.gnu.org/gnu/nano/ includes nano-2.9.7.tar.xz, which was built precisely in the same manner that you would build it, by a developer who had autotools on their machine and ultimately ran 'make dist'. So, rather than building from nano.git, just build the pre-built tarball. I have not used the 'make dist' argument before, but it would prerequisite that I chose the appropriate configure and make arguments to compile for the platform I am targeting.thoughts? 'make dist' is SUPPOSED to produce an idempotent and complete tarball (modulo noise like changes in timestamps), independent of what configure options you used (if it doesn't, that's a bug in the particular package you are trying to build). 'make distcheck' tries to check that this is actually the case, by forcefully creating a tarball, faking a PATH with no autotools, and performing a VPATH build from the tarball, to exercise what an end user without autotools is likely to encounter (not all developers use 'make distcheck' the way they should, but it's part of the GNU Coding Standards, and automake tries to promote it for developers). I am not even sure of the official 'name' of the system I am targeting? s390? omvs? To be clear, I am targeting USS on zSystems, not Linux on z. Thoughts? Best practices? Running config.guess (which is included in many different tarballs, again because automake finds it useful) should give the 'official' name of your system, at least in terms that the autotools cater to. Admittedly, very few people use USS on zSystems while ALSO trying to use lots of GNU software, so it's highly likely that you have a LOT of non-portable assumptions to overcome when porting open source software to your platform (such as the 10-year-old autoconf bug you just reported, where we regressed from something that worked to something that tickles a latent bug in m4's eval that has been present even longer). And actually fixing those bugs may require patching configure.ac or Makefile.am, at which point the 2-machine approach requires making the tweak, rerunning 'make dist', and copying over the new tarball for each tweak you want to test. But having the separation between devel and build machine, even if it involves a lot of iterative copying, may still be easier than trying to have the build machine BE the development machine, where you have to get an entire ecosystem of software running before you can directly build from git instead of from tarballs. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
copyright problem with install-sh, request for clean-room rewrite
can now review which lines remain unchanged from our original copy into the current age, and see that it is mostly comments or bare control flow, which on its own doesn't do much: $ git diff -w -b 042e80a712..HEAD lib/install-sh | sed 's/^[^ ].*//' | cat -s #!/bin/sh # install - install a program, script, or datafile # # Calling this script install-sh is preferred over install.sh, to prevent # when there is no Makefile. # # This script is compatible with the BSD install script, but was written # from scratch. rmcmd="$rmprog -f" case $1 in -g) chgrpcmd="$chgrpprog $2" shift fi esac done exit 1 else fi dst=$src else # might cause directories to be created, which would be especially bad # if $src (and thus $dsttmp) contains '*'. exit 1 fi exit 1 else fi else fi shift else fi done fi fi # If any of these fail, we abort the whole thing. If we want to # ignore errors from any of these, just make sure not to ignore # Now rename the file to the real destination. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: copyright problem with install-sh, request for clean-room rewrite
On 09/03/2018 01:24 PM, Paul Eggert wrote:
Mathieu Lirzin wrote:
According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.
Thanks for volunteering.
Indeed, and I think you are reasonably safe for the task.
Eric, do you think it would save time overall
if you sent him the part of install-sh that you are sure is *not*
problematic, i.e., the part that is already copyright by the FSF? That's
typical procedure in a cleanroom rewrite of anything large; dunno if
it's overkill here.
One thing that is for certain copyright by the FSF is the fact that
'install-sh --help' outputs a useful summary (as the original install-sh
merely reports "install: --help does not exist"). So here's a nice
starting point:
$ lib/install-sh --help
Usage: lib/install-sh [OPTION]... [-T] SRCFILE DSTFILE
or: lib/install-sh [OPTION]... SRCFILES... DIRECTORY
or: lib/install-sh [OPTION]... -t DIRECTORY SRCFILES...
or: lib/install-sh [OPTION]... -d DIRECTORIES...
In the 1st form, copy SRCFILE to DSTFILE.
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
In the 4th, create DIRECTORIES.
Options:
--help display this help and exit.
--version display version info and exit.
-c(ignored)
-Cinstall only if different (preserve the last data
modification time)
-dcreate directories instead of installing files.
-g GROUP chgrp installed files to GROUP.
-m MODE chmod installed files to MODE.
-o USER chown installed files to USER.
-sstrip installed files.
-t DIRECTORY install into DIRECTORY.
-Treport an error if DSTFILE is a directory.
Environment variables override the default commands:
CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
RMPROG STRIPPROG
Other black-box testing that I can readily describe is based on how
automake uses the script (as those are the command line invocations that
must work; it may be easier to start with a rewritten script that is
less full-featured than what the current one does, as long as it
provides everything that automake actually uses it for):
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
...
mkinstalldirs = $(install_sh) -d
...
INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
...
-test -n "$(am__skip_mode_fix)" \
|| find "$(distdir)" -type d ! -perm -755 \
-exec chmod u+rwx,go+rx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r "$(distdir)"
...
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS)
INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)"
INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS)
INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)"
INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
...
Comparing to GNU coreutils, which also ignores -c, I have no idea why
Automake's snippets that use $(install_sh) pass -c; and while I see a
definite use of -d, -m, -s, and $STRIPPROG, I don't see an obvious use
of -g, -o, -C, or some of the other environment variables, at least for
what automake itself expects to exist (although it's harder to predict
what functionality other projects have come to rely on in their
Makefile.am usage of install-sh).
I also note that 'lib/mkinstalldirs' has a different copyright/license
(namely, "Public domain"), where I don't know if we need to rewrite that
one as well; and find it odd that we also have a line in generated
Makefiles that uses 'install-sh -d' in place of mkinstalldirs. It may
make sense to have automake quit shipping mkinstalldirs, and merely rely
on $(MKDIR_P) and/or 'install-sh -d', for one less helper script
installed by automake.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: copyright problem with install-sh, request for clean-room rewrite
On 09/03/2018 10:35 AM, Thomas Dickey wrote: On Mon, Sep 03, 2018 at 09:13:13AM -0500, Eric Blake wrote: ... Note that the most recent version of 'install-sh' as installed by Automake states: # Copyright (C) 1994 X Consortium looking at my collection of untarred X sources, there's an issue with that: Thanks for digging up more history. With all that, the available information shows that someone "fixed" things in the early 2000s by adding a copyright date to address the derived work. Git blame points to Automake commit 7bb3bbe6e: commit 7bb3bbe6e2560604a2f925fec6ff7b4afd74e180 Author: Alexandre Duret-Lutz Date: Fri May 9 17:58:21 2003 + * lib/install-sh: Update copyright notice and license to that of X11R6. This removes an advertising clause reported as Debian bug #191717. http://bugs.debian.org/191717 is an interesting read, pointing out that versions of automake prior to that point had: -# Copyright 1991 by the Massachusetts Institute of Technology -# (FSF changes in the public domain.) [with an advertising clause] before what now reads as: +# Copyright (C) 1994 X Consortium [with no advertising clause] In turn, that copyright line first appeared in commit 4314bddf in Jul 1996, prior to which point it was indeed shipped without a copyright line. Perhaps autoconf's source repo has additional information. Looking there, it has moved over time (from the top level, to config/install-sh, to now build-aux/config.sh). The initial commit there in 1994 indeed had no copyright (see commit 430e0b6), and the MIT copyright notice was added in Jul 1996 (commit ce6c1f20) - looks like autoconf and automake were kept relatively close in sync at that time, and only later with commit 383913b4 in Sep 1998 did autoconf start syncing install-sh from a different location rather than maintaining it in parallel with automake. As is, the copyright was apparently not applied by the owner of the file. So the sentence in the autoconf manual was, at least at one point in history, correct about the file not carrying a copyright; but is now out of date based on what subsequent modifications have pulled in (although tracking actual copyright may be a lot harder than just doing a clean-room rewrite). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automatically showing test-suite.log on failure?
[adding autoconf, as this also affects testsuite.log generated by
projects using autotest instead of automake's built-in support]
On 9/21/18 12:37 PM, Bob Proulx wrote:
Bob Friesenhahn wrote:
Karl Berry wrote:
However, this seems like it would be fairly commonly useful and easy
enough to do in the canonical test-driver script. So, any chance of
adding it as a standard feature? Any reasonable way of enabling it would
be fine, e.g., a flag that can be added to [AM_]LOG_DRIVER_FLAGS.
Take care since some test logs could be megabytes in size.
I want to put a point in that often users try to be helpful and email
that multi-megabyte log file as an email attachment to bug reporting
mailing lists that sometimes have a lot of subscribers. This is very
painful on the network bandwidth usage. And also every downstream
subscriber, perhaps on a metered cell modem data plan, pays the cost
of receiving it whether they can help with it or not.
If there is some way, clever or not, to encourange the user to
compress that log file before attaching it that would save a lot of
downstream pain. When compressed that log file is a small fraction of
the original size and rarely a problem.
Just mentioning it to keep it in the brain cache when thinking about
improvements here. :-)
Indeed - I almost wonder if it would be worth patching the sequences
that generate testsuite.log to automatically generate a compressed
version in parallel, and in the output when a test fails, mention that
the user may inspect testsuite.log but should email the compressed
testsuite.log.XYZ to the developer. Determining the best compression
program to recommend is interesting - if the user is testing a package
that shipped only as foo.tar.xz, then testsuite.log.xz makes the most
sense to generate; but if foo ships both foo.tar.gz and foo.tar.xz, it
is not obvious which form the user uncompressed and would require a
configure or runtime probe for which compression engine to attempt.
If nothing else, autoconf should be patched where it states:
echo
if $at_debug_p; then
at_msg='per-test log files'
else
at_msg="\`${at_testdir+${at_testdir}/}$as_me.log'"
fi
AS_ECHO(["Please send $at_msg and all information you think might help:
in lib/autotest/general.m4, to mention the recommendation for compression.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: if-else if condition in Makefile.am
On 11/28/18 7:08 PM, Deepa Ballari wrote: Hello, How do I write if-else-if condition (or nested if condition) in Makefile.am? Code: if NEWLIB_NANO_FORMATTED_IO LIBADD_OBJS = \ $(lpfx)nano-vfprintf_float.$(oext)\ $(lpfx)nano-svfprintf.$(oext)\ .. else if NEWLIB_FORMATTED_IO LIBADD_OBJS = \ $(lpfx)newlib-vfprintf.$(oext) $(lpfx)newlib-vfprintf_longdouble.$(oext) \ else LIBADD_OBJS = \ .. $(lpfx)svfiwscanf.$(oext) $(lpfx)svfwscanf.$(oext) \ $(lpfx)vfiwscanf.$(oext) $(lpfx)vfwscanf.$(oext) endif if NEWLIB_NANO_FORMATTED_IO LIBADD_OBJS = ... else !NEWLIB_NANO_FORMATTED_IO if NEWLIB_FORMATTED_IO LIBADD_OBJS = ... else !NEWLIB_FORMATTED_IO LIBADD_OBJS = ... endif !NEWLIB_FORMATTED_IO endif !NEWLIB_NANO_FORMATTED_IO You just have to nest things on separate lines, with one endif per if/[else]. The comments after else and endif are optional, but I find they make it a lot easier to reason about things when dealing with nested conditionals. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Libguestfs] [nbdkit PATCH] build: Install ocaml files relative to --prefix
[adding the automake list, in case someone has advice] On 12/7/18 4:22 PM, Richard W.M. Jones wrote: On Fri, Dec 07, 2018 at 03:09:43PM -0600, Eric Blake wrote: Rather than always trying to install ocaml files into $(OCAMLLIBS), which is likely to be root-owned and therefore fail during a './configure --prefix=$HOME/subdir', we instead choose to always install relative to $(prefix) and let distro packagers take steps post-install to move the distro's pre-built copy into the correct location for the distro. This fixes a 'make distcheck' failure. Signed-off-by: Eric Blake --- plugins/ocaml/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/ocaml/Makefile.am b/plugins/ocaml/Makefile.am index b95f255..bbde5e1 100644 --- a/plugins/ocaml/Makefile.am +++ b/plugins/ocaml/Makefile.am @@ -39,7 +39,7 @@ EXTRA_DIST = \ if HAVE_OCAML -ocamllibdir = $(OCAMLLIB) +ocamllibdir = $(libdir)/ocaml ocamllib_DATA = NBDKit.mli NBDKit.cmi NBDKit.cmx NBDKit.o NBDKit.cmi: NBDKit.mli I'm actually one of the authors of m4/ocaml.m4. Could that file be fixed to provide a better $(OCAMLLIB)? No. You _can't_ change $(OCAMLLIB) directly, because it is used for more than just an installation location (I tried, and then compilation started failing when it couldn't find ocaml-specific .h files). The problem is tying ocamllibdir to $(OCAMLLIB), not $(OCAMLLIB) itself. I suspect however the answer will be no. Because what we're really getting is the output of ‘ocamlc -where’. Unfortunately if people are using the opam package manager which installs OCaml in your home directory then ‘ocamlc -where’ will be some directory under $HOME and entirely unrelated to $(libdir). Thus I think this patch won't work ... It's a classic problem - if our package wants to install add-ins usable by a third-party, asking the third party where it was installed does NOT mean that WE can install in the same place. And most packages haven't figured out that making it easy to ask 'where should I install MY add-ons so that they can then be easily linked into your project as third-party addons' is a much different question than 'where do you load your third-party addons from'. If it were a standard FHS location, the GNU Coding Standards might have recommended an approach of './configure --ocamldir=...', but that doesn't scale to every possible combination of packages that want to install 3rd-party modules usable by other packages. I'm not upset if this patch doesn't go in, but if it doesn't, I'm stumped at how to get 'make distcheck' to work around the problem of skipping installation to an absolute directory outside of --prefix. Again, I think it's nicer to have './configure --prefix=$HOME/subdir; make; make install' install everything locally, and then follow up as needed with a post-install action to move (or copy/symlink/install) 3rd-party modules from there into their final useful location (creating an .rpm or .deb would be the typical place to do such scripting when building the package in a form intended to be shipped as part of a distro). What's annoying about this is that we DO honor $(DESTDIR), which is great for working around attempts to install into a root-owned directory; but DESTDIR installs are not the same as --prefix=$HOME/user installs. Maybe if there were some way to automate a mode where anything starting with --prefix is installed normally, but anything with an absolute name is installed via DESTDIR, all on the same 'make install' run, and then check that the union of those two install locations makes sense. But that would be a new automake feature, and no telling how long it would take before packages can rely on distros shipping an automake that new. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: autoreconf and depcomp
On 2/2/19 12:18 AM, bill-auger wrote: > when i run `autoreconf -ivf` and a 'depcomp' already file exists, > 'depcomp' gets added to 'am__DIST_COMMON' in ./Makefile.in - but when i > run `autoreconf -ivf` and the 'depcomp' file does not exist, it is > recreated automatically but is not added to 'am__DIST_COMMON' > > can someone advise me if i should be concerned about this quirky > behavior The contents of the generated Makefile.in result from Automake; so even though autoreconf belongs to Autoconf, any fix to this issue will have to come from a patch to Automake. Updating mail distribution accordingly. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: autoreconf doesn't follow includes.
Adding the automake list, since that is the impacted project: On 2/21/19 1:05 PM, Carlo Wood wrote: > Hi, > > I'm using a Makefile.am that has an include, like so: > > ---begin of Makefile.am--- > include $(srcdir)/cwm4/root_makefile_top.am > > SUBDIRS = googletest @CW_SUBDIRS@ src > > include $(srcdir)/cwm4/root_makefile_bottom.am ---end of Makefile.am > ---end of Makefile.am > > I do this because every project that I have is the same, except for > SUBDIRS :p. > > This works fine with all autotools except autoreconf; > for example > > sean:~/projects/aicxx/ai-evio-testsuite/ai-evio-testsuite>autoreconf -v -i -s > --no-recursive > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal > > which is wrong because autoreconf ignores the line > > ACLOCAL_AMFLAGS = -I cwm4/aclocal -I m4/aclocal > > in $(srcdir)/cwm4/root_makefile_top.am > > See https://www.gnu.org/software/automake/manual/html_node/Include.html > why this is legal usage of automake. Makefile fragments are valid, but it is not immediately obvious if makefile fragments are allowed to have ACLOCAL_AMFLAGS that affect the overall file, or if it is better to put ACLOCAL_AMFLAGS directly in the primary file rather than hidden in an include file. At any rate, if automake is happy finding that definition after chasing through includes, I'm happy to accept a patch to autoreconf to do similar chasing when building the command line to pass to automake, but I'm not sure how easy it would be for me to write the patch myself. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: AC_ARG_ENABLE and checking for unrecognized switches
On 3/14/19 10:56 PM, Kip Warner wrote: > Hey list, > > I use AC_ARG_ENABLE to create a number of different --enable switches. > I noticed when I accidentally mistyped the in --enable- > , ./configure didn't bail on the unrecognized switch. This is by design; the GNU Coding Standards wants projects to be aggregatable, such that someone else could write a larger project that uses yours as a subdirectory, and takes additional --enable switches that some (but not all) of its subprojects understand. Being able to blindly pass down all of its switches to subprojects, without having to worry about which projects care about which switches, makes this easier. > > Is there something I need to add to configure.ac in order to get it to > do this? Unfortunately, since it is by design that unknown --enable arguments are ignored, I don't know of a handy way to switch that behavior to warn or fail instead. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: A new, novel, and faster Binary Search algorithm
On 3/15/19 6:16 AM, Gregorius van den Hoven wrote: > My apologies. The algorithm is licensed under GPL 3 so it seemed relevant > to the GNU community to me. Do you have a suggestion for a more appropriate > mailing list? Perhaps GNU coreutils (coreut...@gnu.org), as the owner of the sort(1) utility, which would be the most likely program to pick up the use of this code? Or to glibc, to see if it is worth improving qsort() by using the ideas in your algorithm? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Relative path without realpath
On 10/9/20 10:46 AM, Cristian Morales Vega wrote:
> I would like to send some patches making pkg-config files relocatable.
> pkg-config offers the "pcfiledir" variable to do this.
> The thing is that I need to be able to obtain prefix, libdir,
> includedir, etc. relative to the directory where the .pc file gets
> installed. I can easily do this with realpath, from coreutils, but
> it's not POSIX and I'm not sure people will accept such a dependency.
> The use of automake per se has no dependency to coreutils, does it?
>
> There is any way to obtain the path of one directory relative to
> another in automake without adding a new dependency? "realpath"
> implemented as a m4 macro, maybe?
https://stackoverflow.com/questions/2564634/convert-absolute-path-into-relative-path-given-a-current-directory-using-bash
suggests that it can be scripted in portable shell (although I did not
test if it has odd corner cases when one or the other input contains
things like foo/../bar or symlinks):
#!/bin/sh
relpath () {
[ $# -ge 1 ] && [ $# -le 2 ] || return 1
current="${2:+"$1"}"
target="${2:-"$1"}"
[ "$target" != . ] || target=/
target="/${target##/}"
[ "$current" != . ] || current=/
current="${current:="/"}"
current="/${current##/}"
appendix="${target##/}"
relative=''
while appendix="${target#"$current"/}"
[ "$current" != '/' ] && [ "$appendix" = "$target" ]; do
if [ "$current" = "$appendix" ]; then
relative="${relative:-.}"
echo "${relative#/}"
return 0
fi
current="${current%/*}"
relative="$relative${relative:+/}.."
done
relative="$relative${relative:+${appendix:+/}}${appendix#/}"
echo "$relative"
}
relpath "$@"
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
[adding in coreutils, for some history] On Sat, Mar 30, 2024 at 12:55:35PM -0400, Eric Gallager wrote: > I was recently reading about the backdoor announced in xz-utils the > other day, and one of the things that caught my attention was how > (ab)use of the GNU build system played a role in allowing the backdoor > to go unnoticed: https://openwall.com/lists/oss-security/2024/03/29/4 I'm also wondering whether the GNU system should recommend using zstd instead of or in addition to xz for compression purposes. Automake gained support for dist-zstd back in 2019 [1], but I'm not sure how many projects are using it yet. [1] https://git.savannah.gnu.org/cgit/automake.git/commit/?id=5c466eaf Furthermore, I was around when GNU Coreutils kicked off the initial push to support dist-xz (initially named dist-lzma, before a change in upstream [2]) because of its benefits over over dist-bz2 (compresses smaller, decompresses faster) [3][4], and even when it ditched dist-gzip leaving dist-xz as its ONLY release option [5][6], before needing to be reinstated for bootstrapping Guix [7][8]. [2] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b52a8860 [3] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b75e3b85 [4] https://lists.gnu.org/r/bug-coreutils/2007-10/msg00165.html [5] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e1c589ec [6] https://lists.gnu.org/r/coreutils/2011-10/msg0.html [7] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=516cdf38 [8] https://lists.gnu.org/r/coreutils/2020-02/msg00042.html At any rate, it is now obvious (in hindsight) that zstd has a much larger development team than xz, which may alter the ability of zstd being backdoored in the same way that xz was, merely by social engineering of a lone maintainer. It is also obvious that having GNU distributions available through only a SINGLE compression format, when that format may be vulnerable, is a dis-service to users when it is not much harder to provide tarballs in multiple formats. Having multiple tarballs as the recommendation can at least let us automate that each of the tarballs has the same contents, although it won't make it any more obvious whether those contents match what was in git (which was how the xz backdoor got past so many people in the first place). -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
Re: [bug-gnulib] proposal for fdl module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Adding automake] According to Bruno Haible on 7/11/2006 5:59 AM: > If this was doc targeted to end-users, this might make sense. But so far > only getdate.texi is an end-user doc. All other doc in gnulib is targeted > at programmers, and should therefore not be incorporated in the package > that uses gnulib. Actually, regexprops-generic.texi is also end-user doc, which CVS Head of M4 wants to incorporate. > >> 2006-07-10 Eric Blake <[EMAIL PROTECTED]> >> >> * gnulib-tool: Avoid space-tab. > > What's the point of this change? Also, please present unrelated patches > in different mails, and commit them in different cvs commits. Otherwise > it gets hard to track the history in CVS. Sorry, I had already committed before I saw your mail. The point was that we might as well follow our own medicine - Makefile.maint discourages space-tab sequences, becase emacs whitespace mode converts them to plain tab. Using tab-space instead makes it obvious that both characters were intended, without having to fight editors trying to collapse them. > >> (--doc-base): Add new option, for where .texi files should live. > > Before doing this, I think we should clarify the distinction between > end-user and gnulib-user doc. I'm adding this to the README. > > *** README 4 Jan 2006 19:18:29 - 1.15 > --- README 11 Jul 2006 11:55:11 - > *** > *** 59,64 > --- 59,70 > * If the module needs configure-time checks, write an autoconf > macro for it in m4/.m4. See m4/README for details. > * Write a module description modules/, based on modules/TEMPLATE. > + * If the module contributes a section to the end-user documentation, > + put this documentation in doc/.texi and add it to the "Files" > + section of modules/. Most modules don't do this; they have only > + documentation for the programmer (= gnulib user). Such documentation > + usually goes into the lib/ source files. It may also go into doc/; > + but don't add it to the module description in this case. > * Add the module to the list in MODULES.html.sh. > > You can test that a module builds correctly with: > > > Also, in the patch, I would mention --doc-base before --tests-base. > (tests-base is used only when --with-tests is specified, whereas doc-base > is used always.) Should I go ahead and update what I committed to make this change? > >> * modules/fdl: New module, for grabbing fdl.texi. > > Automake is distributing COPYING and texinfo.tex. Why would you have > fdl.texi distributed by gnulib-tool, not by automake? I would not like > to see conflicts arise between automake and gnulib-tool. > You had the earlier proposal of making automake be smart enough to install the latest upstream version of docs, rather than the version that was current when automake was released (but most likely out of date at the time that automake is used on a package). If that is done, then I could see making fdl.texi a responsibility of automake. But for now, I find it much more convenient to use gnulib, which is already an up-to-date repository, as the source of COPYING, texinfo.tex, etc., rather than relying on the out-of-date versions that automake would install. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEs6MY84KuGfSFAYARAtNUAKCR4ayeP57m8I+NjTvP5/D9qr2/7gCggpXB zw2gkhLRQPIIDPxfqgrvZrg= =88sa -END PGP SIGNATURE-
request for pkglibexecdir
GNU Coding Standards recommend that packages install their subsidiary executables in a subdirectory of $(libexecdir), suggesting $(libexecdir)/ $(PACKAGE)[1]. CVS m4 wants to use this idiom for installing its libtool modules, rather than $(pkglibdir) which is for object code used in linking rather than shared libraries for dlopen'ing. It would be nice if automake provided $(pkglibexecdir) alongside $(pkglibdir) and friends. [1] http://www.gnu.org/prep/standards/standards.html#Directory-Variables -- Eric Blake
depcomp deficiency [was: m4-1.4.7 build feedback]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Nelson H. F. Beebe on 9/26/2006 8:51 AM: > Machinetype:Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); > FreeBSD 6.1-RELEASE #0 > Configure environment: CC=/usr/bin/c89 CFLAGS=-I/usr/local/include > CXX=/usr/bin/g++ > > if /usr/bin/c89 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../lib > -I/usr/local/include -MT m4.o -MD -MP -MF ".deps/m4.Tpo" -c -o m4.o m4.c; \ > then mv -f ".deps/m4.Tpo" ".deps/m4.Po"; else rm -f ".deps/m4.Tpo"; > exit 1; fi > c89: illegal option -- M > usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] > ... >[-o outfile] [-U name] ... operand ... > >where operand is one or more of file.c, file.o, file.a >or -llibrary > make[2]: *** [m4.o] Error 1 > > This also happens with c99. Their manual pages say > > NAME >c89 -- POSIX.2 C language compiler > > SYNOPSIS >c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L > directory] ... >[-o outfile] [-U name] ... operand ... > > DESCRIPTION >This is the name of the C language compiler as required by the > IEEE Std >1003.2 (``POSIX.2'') standard. > > NAME >c99 -- standard C language compiler > > SYNOPSIS >c99 [-cEgs] [-D name[=value]] ... [-I directory] ... [-L > directory] ... >[-o outfile] [-O optlevel] [-U name] ... operand ... > > DESCRIPTION >This is the name of the C language compiler as required by the > IEEE Std >1003.1-2001 (``POSIX.1'') standard. > > They recognize only the very limited set of options show in the > synopses, but under the hood, they invoke /usr/bin/cc, which is > gcc 3.4.4. What a wimpy compiler wrapper. If they're going to wrap gcc, they might as well recognize options that are pure POSIX extensions rather than crashing on them. > > Tests with c89 and c99 show that they define the symbol __GNUC__ to 3, > so configure concludes they are gcc: > > checking for gcc... /usr/bin/c89 > checking whether we are using the GNU C compiler... yes > checking dependency style of /usr/bin/c89... gcc3 > > The src/Makefile has the rule > > .c.o: > if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \ > then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f > "$(DEPDIR)/$*.Tpo"; exit 1; fi > > but that fails because of the limited option repertoire of c89 and > c99. > > It is probably not worth trying to fix this, although doing so would > likely enhance portability to a wider range of c89 and c99 compilers > on other systems. In short, the problem here is that the depcomp algorithm for determining what dependency checking to request is being fooled by the fact that your compiler claims to be gcc thanks to its definition of __GNUC__, then fails to recognize -M options for dependency checking. A fix would have to come from automake, which maintains depcomp, to gracefully try whether -M actually works before deciding that a compiler is really gcc3 compatible. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGeAn84KuGfSFAYARArfkAKCZ4w4Yu7fxcI8BFvZV3VDnrGgRKwCgv8BR uTnxBu2fYqylmLtvoxSrtuM= =p+uu -END PGP SIGNATURE-
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Nelson H. F. Beebe on 9/27/2006 7:23 AM: > Thanks for the comments on the automake testing in the depcomp > code. > > > Here is what POSIX (IEEE Std 1003.1-2001: Revision of IEEE Std > 1003.1-1996 and IEEE Std 1003.2-1992) has to say: ... > As far as I can see, POSIX-2001's requirements for compiler options > are met by the BSD c89 and c99. In particular, there are no > provisions for generation of dependencies, like gcc's -M option family > offers. Yes, we are aware that -M is not standardized. That is why depcomp knows several flavors of how to generate dependency tracking, including a method that involves no compiler support (by looking at preprocessor output in a separate process instead). By default, automake projects turn on dependency tracking for compilers that can do something like -M, where the dependency tracking is a side-effect of compilation with minimal overhead, and leaves it off for compilers that require a separate process. The problem that you reported is that you have a compiler that fooled automake's depcomp into thinking it supported side-effect dependency when it really didn't. > > I've never understood why some packages feel the need to generate > dependencies at build time at every end-user site, rather than at a > single developer site. In my own packages, I maintain the Makefile > dependencies myself, and don't require their generation during builds. Then you should use './configure --disable-dependency-tracking' - this is exactly what it was invented for. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGn7Z84KuGfSFAYARAqzaAJ9b5cSpx5s0R4Ygida/llAlKPPJfgCeIjFq SOcgSHb1dmp6XoBzhZ8yR0g= =izMx -END PGP SIGNATURE-
Re: depcomp deficiency [was: m4-1.4.7 build feedback]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andreas Schwab on 9/27/2006 8:00 AM: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > >> The issue is >> much more special in this case: the FreeBSD compiler wrapper c89 >> accepts the options >> -MP -MD -MF -MT >> >> if they appear _after_ all the other command line arguments, > > The wrapper probably just stops parsing options at the first non-option, > and passes all remaining arguments unchanged. Which sounds like a bug in the wrapper to me (like the one that was just fixed in the post coreutils 6.2 groups script). If they really want to stop parsing options, and pass all remaining arguments to gcc, then they should be using -- between the options they give gcc and the remaining arguments that they pass unchanged. But as long as that bug in the wrapper is still present, we might as well exploit it in depcomp :) - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGxns84KuGfSFAYARAppXAKCOBXg3JyqwuAhcvV4+uJpL4sFJowCfQLEc CM6NSC8wavF/lnzvoENwu5Q= =oJBv -END PGP SIGNATURE-
bug in --version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the 1.10 release! However, 'automake --version' does not comply with GNU Coding Standards. The Copyright line is missing "(C)" before the year, and the GCS recommends that the copyright appear on the second line, with the authors appearing after the copyright/warranty. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFMto684KuGfSFAYARAm9pAJ0XZ8ND242dQk8QdR5rQe6kPvsJVQCfWTkJ r4HKBBjWSR4vdBE1AeV4Gjs= =JnpL -END PGP SIGNATURE-
Re: bug in --version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 12/3/2006 2:26 AM: > Hello Eric, > On Sun, Oct 15, 2006 at 07:02:50PM -0600, Eric Blake wrote: >> >> Thanks for the 1.10 release! However, 'automake --version' does not >> comply with GNU Coding Standards. The Copyright line is missing "(C)" >> before the year, and the GCS recommends that the copyright appear on the >> second line, with the authors appearing after the copyright/warranty. > > Thanks for the report. OK to apply? What about other scripts owned by autoconf, such as compile, depcomp, install-sh, missing, ylwrap...? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFcuio84KuGfSFAYARAmn/AJ9gNQvEmWWr9GG+sQ8arTWA1WzzhgCdHZ5H RT68sOZkaq2rKPQHIuUxRFY= =Z6JT -END PGP SIGNATURE-
Re: bug in --version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 12/3/2006 8:09 AM:
> According to Ralf Wildenhues on 12/3/2006 2:26 AM:
>> Hello Eric,
>> On Sun, Oct 15, 2006 at 07:02:50PM -0600, Eric Blake wrote:
>>> Thanks for the 1.10 release! However, 'automake --version' does not
>>> comply with GNU Coding Standards. The Copyright line is missing "(C)"
>>> before the year, and the GCS recommends that the copyright appear on the
>>> second line, with the authors appearing after the copyright/warranty.
>> Thanks for the report. OK to apply?
>
> What about other scripts owned by autoconf, such as compile, depcomp,
^^^^
I meant automake, obviously
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFcujz84KuGfSFAYARAv90AKDGnSuv4aozF8rzIr807mrhAiimjACgxuIo
vMrvyI4FGnq0kwCXjiB60pk=
=Q9it
-END PGP SIGNATURE-
Re: Migration to Git?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Benoit SIGOURE on 9/30/2007 10:10 AM: > On Sep 30, 2007, at 5:59 PM, Ralf Wildenhues wrote: > >> Hello Benoit, all, Hello, > >> For Automake, Alexandre should be asked; FWIW my position is the same as >> for Libtool; but note that Automake CVS is currently not hosted on >> savannah. Hosting the git repository on savannah requires project admin rights. I was recently granted those rights for Autoconf (hence the autoconf conversion), but do not have them for Automake or Libtool, or else I would have offered to convert those too. > > Uh. I've always done `cvs -z3 > -d:pserver:[EMAIL PROTECTED]:/sources/automake co .` to > fetch automake. Is automake officially hosted at redhat? Yes. Write access goes through sources.redhat.com (aka sourceware.org, aka cygwin.com, aka gcc.gnu.org); then someone has a mirroring script to keep the savannah repository up-to-date. > Or sourceware > maybe? I presume this is for historical reasons, but would it be a > problem if automake moved to [EMAIL PROTECTED] + read-only CVS? How are the > CVS repositories at Savannah and RH/Sourceware/whatever sync'ed together? Right now, the Autoconf CVS repository at cvs.sv.gnu.org is manually synced with the git repository (ie. if I check in to git, then I run git-cvsexportcommit to push it to the CVS tree; if someone else were to check in to CVS, I would rerun git-cvsimport to grab it back to git). The gnulib tree officially cut ties to cvs.sv.gnu.org - anyone with write access now gets a failure from the cvs hooks that denies updating the old repository, but it remains accessible for doing 'cvs diff'. Meanwhile, if you convert to a git repository, you can still offer read-only CVS access, via a new host - pserver.git.sv.gnu.org. This is not a separate repository, merely a CVS view into the git repository, so it is automatically up-to-date with git. The m4 git repository also has the pserver access enabled, but there are problems with git handling branches, so I haven't really publicized the link to that new repository yet. Automake and libtool both suffer from the same problem as m4 - namely, there is a release branch and a development branch that are both still being actively maintained, so the git-cvsserver branch serving issues need to be resolved (gnulib and autoconf were nicer, since there is only one active branch). Furthermore, Jim Meyering and Sylvain Beucler are working on updating the savannah web hosting pages to allow pointing to the git CVS mirror instead of the old repository on the CVS instruction pages for each project using git. Once this is done, I will have him do the same thing for Autoconf as has been done for gnulib - namely, turn of write access to the old CVS repository, and no longer publish its address, but still leave it live for doing diffs. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHABRt84KuGfSFAYARAqJHAJ9GufMZStOQ+kWnPg7WViys/fcmeACfcfC+ opK8BVRlOkVCBjMy+heXJiQ= =RbPM -END PGP SIGNATURE-
Re: how to avoid automake dependency?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sam Steingold on 10/22/2007 8:29 AM: > I put some gnulib code into my project (in directory gllib) and now I > _sometimes_ (usually it works) get this error: > > /space/sbcl-arch/autobench/+clisp/src/build-aux/missing --run > automake-1.9 --gnits gllib/Makefile > /space/sbcl-arch/autobench/+clisp/src/build-aux/missing: line 54: > automake-1.9: command not found automake likes recording which release generated a Makefile.in. Perhaps all you need is to run 'autoreconf', which will then regenerate all your Makefile.in from your latest automake version (I'm assuming you have 1.10, but not 1.9, installed on your PATH). Once that is done, future gnulib updates will remember that you used automake 1.10, and no longer insist on trying automake-1.9. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHPIb84KuGfSFAYARAigoAKDJdY8rq0CNeRw27fiEz9hBm4+XgwCgpAs5 x8qgTX2L7h4vfesChrmCy8k= =w/xM -END PGP SIGNATURE-
Re: Custom Build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Kamaljit Singh on 10/26/2007 4:17 PM: > Hi All, > > Is it possible to create custom build targets and dependencies quite like the > one for say C++ ? > For instance - > install_ABC=hello_world > hello_world_SRC=a.xyz b.xyz c.xyz > > where my own "compiler" would "compile" the SRC argument as and would > install it in $(installdir) ??? > > Any ideas how this maybe accomplished ? This looks more like an automake question, so I've redirected the mail accordingly. Perhaps the answer already lies in the automake manual, in creating your own suffix rules: http://sourceware.org/automake/automake.html#index-Adding-new-_0040code_007bSUFFIXES_007d-880 - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIqo+84KuGfSFAYARAj4FAKDCXh9WcSPnzZy+awQjWXJrob3G0QCgpRTb xMsmgCRuEahVDBeqO/jyrJg= =dLZ8 -END PGP SIGNATURE-
Re: new module: xprintf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 10/20/2007 10:31 AM: >> is there a better way to just automatically update po/Makevars (possibly >> by teaching po/Makevars how to include a second file)? > > Not so far. But what I could do in the next gettext release is to use the > configure script as a collector for all the needed options: I could define > a macro AM_XGETTEXT_OPTION([option]) that would augment an AC_SUBSTed > variable which then gets used in po/Makefile, together with the > XGETTEXT_OPTIONS from po/Makevars. How does that sound? Almost sounds okay, except as proposed, you would be injecting another macro into the Automake macro AM_* namespace. Would you please consider renaming your macro to something like GT_XGETTEXT_OPTION, so that automake does not have to continually worry about names from its namespace being consumed by external packages, and so that users trying to write bug reports against the macro have a better chance of guessing which package actually owns the macro? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJdWf84KuGfSFAYARAshAAJ4y8s1ktQvd4+RoAT6BSFTfMLBLsgCdFkI/ JXVHdO4tegCf30jFSea4x8Y= =Riep -END PGP SIGNATURE-
Re: acinclude.m4 warning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Adding automake, since this message is produced by aclocal (part of automake), not autoconf.] According to Taoman Li on 10/29/2007 9:09 PM: > Hi, all > I am using kdevelop on Linux and when I am doing Build->autoconf and friends > > (which is embedded in kdevelop, and using autoconf-2.61) > I go the following warning: > > acinclude.m4:3700: the serial number must appear before any macro definition > > Kdevelop has confirmed this is NOT their concern, and directed me to your > website. > Does Kdevelop have to live with those warnings , or there is a way to get > them off ? They are merely warnings. But if you don't want them, then you should follow their advice, and move the serial number comment on line 3700 to live prior to any macro definitions in your included .m4 files. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJx2Q84KuGfSFAYARAmVbAJ0Wp7YrfLxIGzT4Qk/DOwR+BzaQQgCgqiIK O9Gq4zvPvxXixCSIZPxgY7w= =fqUy -END PGP SIGNATURE-
Re: building with older Automake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 12/4/2007 1:49 PM: > >> I traced it to the fact that I was not using bleeding-edge >> automake. This fixes it, so I'm committing. > > Well, the "fix" would be to release Automake 1.10.1. This is just an > ugly workaround around the licensing holdup. Please let's not go this > way even further. Any time we depend on automake to supply texinfo.tex as a generated file, and also check in the latest texinfo.tex as copied from the gnulib directory which tracks upstream, you are bound to have mismatch eventually. In other words, it doesn't matter what version of automake we are using (even after 1.10.1 is released); texinfo.tex will eventually change in relation to what the released automake installs. Either texinfo.tex should not be tracked in autoconf's git, or automake should be taught how to grab the latest versions at the time it is invoked (rather than the version as it existed when automake was released), or we teach automake to leave texinfo.tex alone since we maintain it externally (by copying it from gnulib). My patch did the latter option. >> or should we up our minimum requirement to 1.9.6 or 1.10? > > Of course that can still be done. I'm also thinking it might be nice if automake provided a witness macro on whether it supports the dist-lzma option, so that we can write autoconf's configure.ac to conditionally enable dist-lzma if the version of automake is new enough, rather than introducing a hard dependency on (as yet unreleased) automake. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHVq2684KuGfSFAYARAiK3AJ96aJWssE4T2yedfABG1BC7Njm3pQCghE9V elmVzKRIOQsskXT3k82d5qs= =+uD/ -END PGP SIGNATURE-
'set -u' and $SHELL in makefiles [was: GNU M4]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-automake; this is http://thread.gmane.org/gmane.comp.gnu.m4.bugs/2388] According to Chan, Lawson on 1/30/2008 12:46 PM: | Hi Eric, | | Thanks for your reply. I am sorry that I have difficulties in removing the disclaimer because it is out of my control. Nothing prevents you from using a free webmail account, or finding a newsreader gateway that won't add a disclaimer (I personally like gmane). | I am running the make in both shell (bash or Korn) and they have exactly the same behaviour. It doesn't matter what shell you ran make from; what mattered is what shell make was running as it spawned commands. What does 'env | grep SHELL' say? Your log shows that you are running bash 2.03, which is rather old, but I don't think that's an issue. I personally know that M4 builds just fine on Solaris 8, so it is something about your environment that caused your failure, and not a flaw in the M4 package. | | /M4/m4-1.4.10/checks | bash: fail: unbound variable | *** Error code 1 | make: Fatal error: Command failed for target 'all-recursive' | | Here is the attached configure and make output file for your reference. You still didn't show me the command lines that you typed. | | Yes, the ./configure is successfully executed. Any thought about this? It looks like an automake issue to me. It looks like you have somehow enabled the 'set -u' option of bash. Looking at what automake outputs for $(RECURSIVE_TARGETS) in each Makefile, I see: $(RECURSIVE_TARGETS): ~@failcom='exit 1'; \ ~for f in x $$MAKEFLAGS; do \ ~ case $$f in \ ~*=* | --[!k]*);; \ ~*k*) failcom='fail=yes';; \ ... ~ || eval $$failcom; \ ~done; \ ~if test "$$dot_seen" = "no"; then \ ~ $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \ ~fi; test -z "$$fail" In other words, if you did NOT use 'make -k', then eval $$failcom never initialized $fail, and test -z "$$fail" ends up expanding an undefined $fail, explaining the bash warning. I've never seen a make implementation use 'set -u' (although I do know that some make use an implicit 'set -e'), and since POSIX requires make to ignore $SHELL from the environment, I'm not quite sure whether the user had a posix-compliant setup to begin with. ~ Then again, POSIX states that it is not portable to assign SHELL within a makefile, while autoconf recommends doing exactly that via [EMAIL PROTECTED]@, and 'set -u' _is_ posix-compliant. So should automake cater to this weird SHELL setting by doing failcom='fail=; exit 1' as the default value for $failcom (and audit for any other potentially unset variables)? Or is it better to figure out how this user got 'set -u' enabled in your SHELL in the first place, and add workarounds (perhaps in autoconf, rather than automake?) to avoid such an awkward setup? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoNjV84KuGfSFAYARAj2lAJoCjxFaHdSDoREq7AHBJg+EGzniCQCeK4TL VcOy9V5e618/oxh/ZycO59Q= =neTy -END PGP SIGNATURE-
Re: 'set -u' and $SHELL in makefiles [was: GNU M4]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Chan, Lawson on 1/30/2008 3:26 PM: | Hi Eric, | | 1) actually, I use the following commands to start the execution. So I am in the bash shell. | Bash | ./configure | make | Even though I am in the bash shell, running the 'env | grep SHELL' gives SHELL=/usr/bin/ksh Makes sense - bash doesn't overwrite SHELL if it was already set when bash started. But there's no need to start bash before running ./configure; it should run just fine from ksh (or even the hideous Solaris 8 /bin/sh), since the first part of ./configure is all about discovering a decent shell if the current shell was not good enough. | 2) $echo $- returns bhimCBH | 3) I normally don't run set -u. I still don't know why it is set initially. It's not. Since $- doesn't contain u, 'set -u' is not active. | 4) I run ./configure in a fresh location and it behaves the same. | 5) The output of 'grep SHELL Makefile config.log' is attached in this email. And it shows merely "SHELL = /bin/bash". No hint of -u, but configure did decide that /bin/bash was a better choice than /bin/sh. | 6) I am using make 3.81. Obviously GNU make, and not Solaris' version. GNU make doesn't add -u, so I'm a bit stumped. | | What about in a temporary directory (and use TAB for indenting): | | $ cat <<\EOF > Makefile | all: | echo - $(SHELL) - $(MAKE) - $(MAKEFLAGS) - $$MAKEFLAGS - EOF $ make | | Then repeat, but with adding the same 'SHELL = ...' line at the beginning that was in m4/Makefile? You didn't run this test. Also, could there be some other environment variables interfering? At this point, the output of 'env' might prove helpful. Anyone else have ideas? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoQWv84KuGfSFAYARAiqJAJ916IwJa1YFS5J2REF8817FIhMczQCdFhHV /Wk+EUKwiblvAJml5PBOTq0= =Zx4p -END PGP SIGNATURE-
Re: traces output order
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Ralf, According to Ralf Wildenhues on 3/21/2008 1:18 AM: | Hmm. That means my current AM_COND_IF patch will treat | | AM_COND_IF([OUTER], | [$outer_action | AM_COND_IF([INNER], | [$inner_action])]) Look at autom4te.cache/traces.?, with lines like: m4trace:configure.ac:3: -1- AM_COND_IF([OUTER], [$o AM_COND_IF([INNER], [$i])]) m4trace:configure.ac:3: -1- AM_COND_IF([INNER], [$i]) | | correctly but mistreat | | AM_COND_IF([OUTER], | $outer_action | AM_COND_IF([INNER], | [$inner_action])) m4trace:configure.ac:5: -2- AM_COND_IF([INNER], [$i]) m4trace:configure.ac:3: -1- AM_COND_IF([OUTER], [$o ...]) | | That's a bit ugly, and certainly deserves mention. I think I see a way around the problem. Use the nesting level, which is also part of the trace. For example, autoconf --trace=_AM_COND_IF:'$n-$d' can tell you that _AM_COND_IF-2 was probably invoked unquoted within _AM_COND_IF-1. For more assurance, you can also start looking at line numbers in the trace to ensure that the subsequent _AM_COND_IF-1 occurs on the same or earlier line than _AM_COND_IF-2, rather than the _AM_COND_IF-2 being nested in an unrelated macro call. Hmm. --trace=MACRO is documented in autoconf/autom4te --help, but not - --trace=MACRO[:FORMAT]. Should we document that in more than the manual? | Happy Easter, Same to you. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfjp/UACgkQ84KuGfSFAYDDXgCgwetjA+DRwcCnl4A3XhDsFZE2 pGUAoJMWJHytp9HCjz+rIScxbgAU4yFW =yVpO -END PGP SIGNATURE-
Re: autoconf-2.62: `make install' fails if file system is case insensitive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-automake and bug-make; this is http://lists.gnu.org/archive/html/bug-autoconf/2008-05/msg0.html] According to Keith Marshall on 5/9/2008 2:16 PM: | If autoconf's Makefile is processed by a GNU make-3.81, which has been | configured to respect a case insensitive file system, (IMO, the correct | configuration for use on MS-Windows, among other other systems which | also have such file systems), and the build is configured directly | within the source directory, then `make install' fails thus: | | $ make install | Makefile:678: warning: overriding commands for target `install' | Makefile:574: warning: ignoring old commands for target `install' | /bin/sh /home/rgbl0264/foobar/foo/autoconf-2.62/build-aux/missing \ | --run makeinfo --no-headers --no-validate --no-split -o install \ | ./doc/install.texi Looking further at this, what happens with your case-insensitive make when running 'make dist' on a project built with 'automake --gnu'? There, automake adds an automatic dependency on all 'dist*' targets to unadorned INSTALL. Does that mean that 'make dist' will attempt to install the package when run on MSYS? Will it just be a no-op because the file INSTALL already exists? Is this something that automake needs to address, by outputting $(abs_srcdir)/INSTALL rather than plain INSTALL in the dependencies of distdir? | | This problem was recently reported by a user on the MinGW users ML: | http://thread.gmane.org/gmane.comp.gnu.mingw.user/26315 | | It is not apparent when performing a VPATH build, but is reproducible | when building in the source directory, both for autoconf-2.62, and for | earlier versions, (I've also confirmed this for autoconf-2.61). Because in a VPATH build, $(srcdir)/INSTALL is different than ./INSTALL, and it looks like case-insensitive GNU make is treating 'make install' and 'make ./INSTALL' as synonyms. Maybe this is also something that should be addressed in GNU make, as case-insensitivity makes following GNU Coding Standards rather difficult? GNU Coding Standards require the existence of both 'make install' and './INSTALL'. | | This issue may be resolved by replacing each of the three references to | `$(srcdir)/INSTALL', in the Makefile, by `$(abs_srcdir)/INSTALL'. I've | confirmed this, by making the appropriate changes in Makefile.in, and | then successfully repeating the `./configure && make && make install' | sequence under MSYS-1.0.11, (with case-insensitive GNU make-3.81), in | the autoconf-2.62 source directory, on MS-Win2K. The attached patch, | against released autoconf-2.62's Makefile.am, will introduce the same | change, on next Makefile.in regeneration. That worked for 'make install', but broke 'make dist'; I'm trying to figure out whether adding: INSTALL: $(abs_srcdir)/INSTALL to autoconf's Makefile.am will be making the problem any worse (at least it fixes the 'make dist' regression when using the normal case-sensitive GNU make). Maybe the short answer is that on MSYS (or anywhere else with case-insensitive GNU make), you should not expect 'make dist*' to work. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhFlgIACgkQ84KuGfSFAYB1ygCfUvdwoLNeVI3ra4TMb0A1d9m4 YFwAn0m/eukAKMi7LuxKb7wKhidq6yzq =C2vT -END PGP SIGNATURE-
Re: how to install data directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matej Tyc on 8/28/2008 1:53 PM: > Hello, > I have a project that I adapt to use Autotools and it is a game. It has > several directories with data that are required by the program that need > to be installed somwhere. > I have used AM_CPPFLAGS = -DDATADIR=\"$(datadir)\" trick and I have > modified the source files accordingly; however the install fails with a > message about omitted directories that are not copied... It is true that > in the corresponding Makefile.am data_DATA=beat/ gfx/ wavs/ are > directories, but I have to install those directories and I would like to > do it in a smart way with as little of work as possible. > Any suggestions? The fact that you mention AM_CPPFLAGS makes this sound more like an automake question than an autoconf one. That said, you may want to look into using dist-hook: http://www.gnu.org/software/automake/manual/html_node/Dist.html#Dist - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki37aoACgkQ84KuGfSFAYBeVACg2AkFEo4yllyBKOD/X1guHzMG J7oAn2klaTWiRb/VGP8AZ5iO7PcGlr7M =bGlC -END PGP SIGNATURE-
Re: How to stop reconfiguration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Václav Haisman on 9/6/2008 3:08 PM: > Hi, > how can I stop reconfiguration (automatic running of aclocal, automake and > autoconf)? I have sources including Makefile.in and configure and other > generated files in Subversion repository. I thought that if I touch each > foo.in file and the configure script, it will not try to re-run autoreconf. This sounds more like an automake question. > But even after that I get: > > amber2::wilx:~/tmp/log4cplus-1.0.3-rc1/objdir> make > > cd .. && /bin/sh /home/wilx/tmp/log4cplus-1.0.3-rc1/missing --run aclocal-1.10 > cd .. && /bin/sh /home/wilx/tmp/log4cplus-1.0.3-rc1/missing --run > automake-1.10 --gnu > cd .. && /bin/sh /home/wilx/tmp/log4cplus-1.0.3-rc1/missing --run autoconf > /bin/sh ./config.status --recheck > running CONFIG_SHELL=/bin/sh /bin/sh ../configure --enable-threads=yes > --no-create --no-recursion This sounds like something that AM_MAINTAINER_MODE would prevent (although personally I don't like using that macro). You may also find it instructive to try 'make -d' to see which dependency make thinks is out of date to trigger the rerun of the autotools. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjC9VYACgkQ84KuGfSFAYBGdwCgsP4XWV9whq1VwzCioAX2S9hV lWIAoLoRodk509c+y+efXtoEpo7hsPcz =v+Hp -END PGP SIGNATURE-
Re: passing autoreconf -I to aclocal -I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding automake list]
According to Clinton Roy on 10/22/2008 5:45 PM:
Hello, Clinton,
> This patch makes autoreconf pass along -I arguments to aclocal, which
> is useful in cases
> where m4 files are installed in sensible, but non standard places
> (like /opt/local/share/aclocal)
Thanks for the patch. Care to add a ChangeLog entry, and wrap the line to
not exceed 80 columns? Meanwhile, I'd like an opinion from automake users
as to whether this patch makes sense to apply, or better reasoning than I
can offer why it is not correct.
>
> diff --git a/bin/autoreconf.in b/bin/autoreconf.in
> index 923f8ca..86e8826 100644
> --- a/bin/autoreconf.in
> +++ b/bin/autoreconf.in
> @@ -186,6 +186,7 @@ sub parse_args ()
>
># Dispatch autoreconf's option to the tools.
># --include;
> + $aclocal.= join (' -I ', '', map { shell_quote ($_) } @include);
>$autoconf .= join (' --include=', '', map { shell_quote ($_) }
@include);
>$autoconf .= join (' --prepend-include=', '', map { shell_quote
($_) } @prepend_include);
>$autoheader .= join (' --include=', '', map { shell_quote ($_) }
@include);
> diff --git a/doc/autoconf.texi b/doc/autoconf.texi
> index 71f507f..2315515 100644
> --- a/doc/autoconf.texi
> +++ b/doc/autoconf.texi
> @@ -1663,7 +1663,7 @@ run @samp{make}.
> @item [EMAIL PROTECTED]
> @itemx -I @var{dir}
> Append @var{dir} to the include path. Multiple invocations accumulate.
> -Passed on to @command{autoconf} and @command{autoheader} internally.
> +Passed on to @command{aclocal}, @command{autoconf} and
@command{autoheader} internally.
>
> @item [EMAIL PROTECTED]
> @itemx -B @var{dir}
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkBJikACgkQ84KuGfSFAYBQkQCeM7jzTYF7vET8Gb6RAdFw1Gqe
nr8AmwX7LZmyRYoHgaO82/fqTY347IyM
=tFa3
-END PGP SIGNATURE-
Re: including autoconf paths in source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Monty Taylor on 12/11/2008 1:38 PM: > Hey all, > > I'm wondering if there is a best practice for getting paths such as > locaeldir or datadir into source code. Best practice is to use the Makefile to do the expansion into another file that gets compiled. For example, see how gnulib does it: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=modules/configmake;h=5160128;hb=58fe6dc - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklB1Z0ACgkQ84KuGfSFAYA4agCeMA6whsYiWHAaWwE0P83tO0Hd nscAoKWTPei+xpsCIpDFskmIuFFZMeoW =d3ra -END PGP SIGNATURE-
resync auto{make,m4te} perl modules?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf's recent work on adding silent-rules to automake modified the lib/Automake/ChannelDefs.pm file on branch je-silent. This file used to by synchronized into autoconf's lib/Autom4te (module difference in the package name); is this still something we want to resync? Whether or not je-silent is merged in, both packages have already made one-sided improvements to the shared files. These range from the simple, such as spelling fixes, to the complex (autoconf added a 'cross' channel for warning about cross-platform issues, while automake has added perl threading to make channel processing more efficient). - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm8LQQACgkQ84KuGfSFAYBVOgCgqO0vHfLALeqoS+AVmPEewiwE UmwAoMsqF0MfvoM9KLg4lV84MpLh2O+v =0ae4 -END PGP SIGNATURE-
Re: [GNU Autoconf 2.63] testsuite: 27 failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [please keep the lists in the loop] According to fireflyxi...@yahoo.com.cn on 3/19/2009 5:50 AM: > Hello Eric Blake, > > Thank you for your suggestion. I upgrade automake to the 1.10.1 version, > but the problem still exits. > You still haven't answered the question on which file system you are using. Until we can figure out why creating a link is failing (perhaps your choice of file system doesn't support hard links, as in VFAT?), we can't explain the error message we were seeing. And then there is still the question of whether automake should work around that, and/or whether it is a flaw in the autoconf testsuite for not dealing with automake's failure to copy. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknCNbEACgkQ84KuGfSFAYAEOwCcCMfwPj5DWr95kgFPlKXvC8fx 0iMAn3mptNyZXTijYD9NLGCStibVO9yq =T6ke -END PGP SIGNATURE-
