bug#79052: epsf.tex: New file

2025-07-19 Thread Bruno Haible via Bug reports for Automake
Simon Josefsson wrote: > Right. I would say that the days of the DVI and PS formats are probably > long gone, and definitely as a default format. PDF has won. DVI yes. PS has its use 1. as alternate format, at least in arXiv.org, 2. as easy-to-create vector graphics format. > I tried to fin

bug#78411: LDADD vs. LDFLAGS

2025-05-13 Thread Bruno Haible via Bug reports for Automake
that avoids this ambiguity. >From 7434f6ebecc536bf79a61f3746253a6618ab9d76 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Tue, 13 May 2025 18:57:00 +0200 Subject: [PATCH] doc: Clarify where to put -L and -l options. * doc/automake.texi (Linking): Clarify that -L and -l options belong in LDADD. --- d

bug#78409: Acknowledgement (LDADD vs. LDFLAGS)

2025-05-13 Thread Bruno Haible via Bug reports for Automake
Short mail sent by mistake. Sorry.

bug#78409: LDADD vs. LDFLAGS

2025-05-13 Thread Bruno Haible via Bug reports for Automake
Hi, The first paragraph in

bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-03 Thread Bruno Haible via Bug reports for Automake
Kirill Makurin wrote: > The installer from https://osdn.net/projects/mingw/ is the same as > found in https://sourceforge.net/projects/mingw/ (except for possible > difference in versions) and the Wikipedia article points to the former > website (mingw.org website is no longer alive). This installe

bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-03 Thread Bruno Haible via Bug reports for Automake
ginal MinGW binaries through a Cygwin environment (which is another mix-up that people might do). Bruno >From fa6a98993ea95ce576c79e597cda5e166f36ba5e Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Mon, 3 Feb 2025 06:02:07 +0100 Subject: [PATCH 1/3] compile: Simplify. * lib/compile

bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-02 Thread Bruno Haible via Bug reports for Automake
s a topic that is widely discussed on the web. 0003) This patch is the same as already proposed: use backslashed filenames instead of forward-slashes ones (that MSYS2 would interpret a second time). Kirill: Testing of this patch series in your environment (MSYS2 + MSVC)

bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-02 Thread Bruno Haible via Bug reports for Automake
path -w", which produces file names like C:\Users\foobar\filename . The *only* situation I've ever seen where "cygpath -m" is required is when the callee is a shell script (with 'echo') that invokes a Java program. (Example: IBM Application Server.) Since the compiler called

bug#74453: running make failed when perl is installed in the very long path

2024-11-26 Thread Bruno Haible via Bug reports for Automake
Nick Bowler wrote: > The Linux program loader expects to find a newline in the first 128 > bytes of the file (increased to 256 in recent versions), otherwise > you will get an ENOEXEC error from execve. My testing indicates: The first line which specifies the interpreter and interpreter args is l

bug#74453: running make failed when perl is installed in the very long path

2024-11-26 Thread Bruno Haible via Bug reports for Automake
Collin Funk cited me: > As Bruno Haible said in a Gnulib thread [1]: > > > "#!/usr/bin/env perl" does not work on GuixSD (where the only program > > that has a hardcoded file name is /bin/sh; there is no /usr and no > > /bin/env on this distro). > > So

bug#71421: system info in test-suite.log

2024-06-07 Thread Bruno Haible
Hi, The 1.16.90 NEWS file states: - test-suite.log now contains basic system information, and the console message about bug reporting on failure has a bit more detail. (bug#68746) 1) This system information is the naked output of some OS commands: (uname -a | awk '{$$2=""; p

bug#71422: no easy way to generate a test-suite.log without skipped tests

2024-06-07 Thread Bruno Haible
r by running make check IGNORE_SKIPPED_LOGS=1 or by defining in the Makefile (or Makefile.am): IGNORE_SKIPPED_LOGS = 1 It includes a unit test, documentation updates, and passes "make check". >From e5ed5248fe4fa5fed521e16929694c9d169540b2 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date:

bug#68179: Re: automake-1.16j on OpenBSD

2024-02-20 Thread Bruno Haible
Bogdan wrote: > # Ensure install-strip works when STRIP consists of more than one word. > # This test needs GNU binutils strip. See sister test 'strip3.sh'. > > > And, frankly, I don't know what to do about this. It's the whole > point of the test to use 'strip --verbose' (well, 'strip' + any

bug#68179: Re: automake-1.16j on OpenBSD

2024-02-20 Thread Bruno Haible
Bogdan wrote: > Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found. > Does it work if you put > > AC_LANG([Objective C]) > > somewhere between the lines > > cat >> configure.ac << 'END' > > and the first > > END > > following it (i.e., in the 'configure.a

bug#68179: Re: automake-1.16j on OpenBSD

2024-02-18 Thread Bruno Haible
Hello Bogdan, > Can you tell us what actually "c++" is on your system? Like e.g. run > "c++ --version" or "c++ --help"? $ c++ --version OpenBSD clang version 13.0.0 Target: amd64-unknown-openbsd7.4 Thread model: posix InstalledDir: /usr/bin > On my system, Autoconf finds "g++", tests it for

bug#68179: Re: automake-1.16j on OpenBSD

2024-02-18 Thread Bruno Haible
Hello Bogdan, Thank you for dealing with the Automake support. > 2) t/strip2 - could you check if you have the STRIPPROG environment > variable set and, if yes, unset it (or, at least, remove the > "--verbose" parameter from it) prior to running the test? I did not have the STRIPPROG environment

bug#68165: automake-1.16j on Solaris 11

2023-12-31 Thread Bruno Haible
0) _ The attached proposed patch fixes it. >From ec1b65eb0e1bef42d1dbfe27b2dd957626890598 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 31 Dec 2023 09:19:46 +0100 Subject: [PATCH] tests: Don't hang on Solaris when flex is not installed. * t/get-sysconf.sh: Don't let $LEX read

bug#68141: automake-1.16j on Ubuntu

2023-12-30 Thread Bruno Haible
On Ubuntu 22.04, with an added symlink python -> /usr/bin/python3 I see a failure: FAIL: t/python-prefix Log file is attached. I think it is the same issue as reported at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64837 . FAIL: t/python-prefix = python-prefix: running

bug#64756: some frequent test failures

2023-11-30 Thread Bruno Haible
Karl Berry wrote: > The various test-suite.log files show different test failures each > > Yes. Painful. I believe this is due to a timing problem with autom4te, > exposed by Automake using fractional second sleeps according to what the > filesystem supports. It is fixed in the autoconf repo

bug#64837: FAIL: t/python-prefix

2023-07-24 Thread Bruno Haible
Hi, With automake master, on an Ubuntu 22.04 system (with Python 3.10), I get a reproducible test failure: FAIL: t/python-prefix Find the log below. If I understand it correctly, the problem is that the test's lines py_inst_site=inst/lib/python$py_version/site-packages and py_installed "$py

bug#64756: some frequent test failures

2023-07-24 Thread Bruno Haible
Thanks for the detailed explanations, Karl. > I bootstrapped and installed autoconf > from its git (as of around June 11) and have used that version with > development automake ever since, and the timing problems have stayed gone. I confirm that with autoconf master, automake's "make check" is re

bug#64743: Speed up GNU make's internal processing

2023-07-20 Thread Bruno Haible
Karl Berry wrote: > I just hope those weird-looking %:: rules do not cause trouble with > other makes. I guess we'll find out. I tested the default 'make' of various OSes, before submitting the patch. Whether some other, rarely-used 'make' implementation has problems with it, we'll find out. > Th

bug#64743: Speed up GNU make's internal processing

2023-07-20 Thread Bruno Haible
> Patch is attached. Here's a corrected patch. (Fixed another test failure.) >From e480457f90748d31601e224ee8d75f766c1a53d6 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Thu, 20 Jul 2023 11:50:51 +0200 Subject: [PATCH] Speed up GNU make's internal processing. Based on a r

bug#64743: Speed up GNU make's internal processing

2023-07-20 Thread Bruno Haible
ake/2023-07/msg00063.html [2] https://lists.gnu.org/archive/html/bug-make/2023-07/msg00067.html >From c8ca5b95a0c322177ba0fb55ddabc1c92fa04f10 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Thu, 20 Jul 2023 11:50:51 +0200 Subject: [PATCH] Speed up GNU make's internal processing. Based

bug#61867: dirstamp pattern rule kills buildability with FreeBSD make, NetBSD make, AIX make

2023-02-28 Thread Bruno Haible
Karl Berry wrote: > I reverted (attempted to, anyway) that change. Thank you. > since evidently @D is not supported on BSD-derived makes, > whatever POSIX says. Nitpicking: I think the problem is not with $(@D), which is inside the rule. The error message Cannot find a rule to create target

bug#61867: dirstamp pattern rule kills buildability with FreeBSD make, NetBSD make, AIX make

2023-02-28 Thread Bruno Haible
Hi, FreeBSD 13.1 'make', NetBSD 9.0 'make', AIX 7.1 and 7.2 'make' are perfectly fine for building many GNU packages, even as VPATH builds. Jim Meyering has now put out a tarball for testing, that uses bleeding-edge Automake: https://lists.gnu.org/archive/html/platform-testers/2023-02/msg00012.ht

bug#61828: aclocal warns when specifying the m4 macro dirs through AC_CONFIG_MACRO_DIRS

2023-02-26 Thread Bruno Haible
I don't understand what's happening in the 'aclocal' program. There is a variable @user_includes with a comment # @user_includes can be augmented with -I or AC_CONFIG_MACRO_DIRS. So, from this comment, it sounds strange that specifying the m4 macro dirs through AC_CONFIG_MACRO_DIRS produces a dif

bug#61828: aclocal warns when specifying the m4 macro dirs through AC_CONFIG_MACRO_DIRS

2023-02-26 Thread Bruno Haible
According to the Autoconf documentation https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Input.html "Packages that use aclocal to generate aclocal.m4 should declare where local macros can be found using AC_CONFIG_MACRO_DIRS." and "Note that if you use acloca

bug#7621: add a way to pass link dependencies

2023-02-13 Thread Bruno Haible
To answer my own question: In 1) I wrote: > Typical values of LTLIBICONV are > > -liconv > -rpath /usr/local/lib -L/usr/local/lib -liconv > /usr/local/lib/libiconv.a > -rpath /usr/local/lib /usr/local/lib/libiconv.so > /usr/local/lib/libiconv.la But that is incorrect. /usr/loc

bug#52500: misleading description of %reldir%

2021-12-14 Thread Bruno Haible
Hi, The documentation https://www.gnu.org/software/automake/manual/automake.html#Include says: "A special feature is that if the fragment is in the same directory as the base Makefile.am (i.e., %reldir% is .), then %reldir% and %canon_reldir% will expand to the empty string as well as eat

bug#44772: 2 test failures in automake 1.16.3

2020-11-20 Thread Bruno Haible
On a glibc system, I'm seeing 2 test failures in automake 1.16.3: $ ./configure --prefix=/arch/x86_64-linux-gnu/gnu-inst-automake/1.16.3 $ make $ make check ... FAIL: t/vala-headers.sh ... FAIL: t/vala-mix2.sh ... Find attached the log files (redacted for privacy reasons). vala and valac exist in

bug#33668: built-in YACC rule generates file in build dir, not source dir

2018-12-07 Thread Bruno Haible
Hi, The Automake-generated Makefile rule for .y files, when run in a VPATH build, produces the generated .c file in the build directory, not in the source directory. How to reproduce: - Unpack the attached hello.tar.gz $ cd hello $ ./autogen.sh $ mkdir vpath $ cd vpath $ ../configure $ make ...

bug#33166: automake --add-missing does not install config.rpath when AM_ICONV is used

2018-12-07 Thread Bruno Haible
> I need iconv but not gettext. Then take the Gnulib module 'iconv'. [1][2] It contains iconv.m4, its macro dependencies, and config.rpath - that is, exactly what you need. Bruno [1] https://www.gnu.org/software/gnulib/MODULES.html#module=iconv [1] https://www.gnu.org/software/gnulib/manual/html

bug#26514: make check - t/gettext-macros.sh hangs

2017-04-15 Thread Bruno Haible
ntroduction of 'autopoint'. But these versions are older than July 2002; we can ignore them by now. 2017-04-15 Bruno Haible * t/gettext-macros.sh: Never invoke gettextize. --- t/gettext-macros.sh.bak 2014-12-31 14:26:32.0 +0100 +++ t/gettext-macros.sh 2017-

bug#11422: automake 1.12 info doc installation problem

2012-05-07 Thread Bruno Haible
Hi Stefano, > I see this report from you on the bug-texinfo list: > > It is a different issue. (But I happened to stumble across both bugs at the same time.) The issue on bug-texinfo is a problem with an INFOPATH that contai

bug#11422: automake 1.12 info doc installation problem

2012-05-06 Thread Bruno Haible
Hi, I have installed automake-1.12 a couple of days ago. In particular the info format documentation was installed as well: $ ls -lrt /arch/x86-linux/gnu/share/info/ ... -rw-r--r-- 1 bin bin 227199 25. Apr 11:16 standards.info -rw-r--r-- 1 bin bin 1142045 25. Apr 11:16 autoconf.info -rw-r--r-- 1

bug#11387: automake 1.12 test failures

2012-05-01 Thread Bruno Haible
Hi, On a bi-arch Linux/glibc system (x86, x86_64) I'm getting 3 test failures when building for 32-bit mode: $ ./configure --host=i686-pc-linux-gnu --prefix=/arch/x86-linux/gnu \ CC="gcc -m32 -march=i586" \ CXX="g++ -m32 -march=i586" \ F77="gfortran -m32

bug#11302: Automake 1.11d on openSUSE 12.1

2012-04-24 Thread Bruno Haible
Hi Stefano, > I went for a different and more reliable fix, i.e., using $(libdir) > instead of $(prefix)/lib, and similarly for the other $(foodir) variables. > > So, does the attached patch fix the problem for you? Yes, it fixes the test failures of t/posixsubst-libraries.sh t/posixsubst-l

bug#11306: Automake 1.11d on MacOS X

2012-04-22 Thread Bruno Haible
Hi Stefano, > > FAIL: t/lex-libobj > > == > > > + ./configure 'LEXLIB=-L /lib' > > checking for a BSD-compatible install... > > /Users/bruno/data/local-macos/bin/install -c > > ... > > + make > > cc -DPACKAGE_NAME=\"lex-libobj\" -DPACKAGE_TARNAME=\"lex-libobj\" ... > > foo.c:1033

bug#11302: Automake 1.11d on openSUSE 12.1

2012-04-22 Thread Bruno Haible
Hi Stefano, > > The test looks for a lib/ directory, but "make install" created a lib64/ > > directory. This is due to the /usr/share/site/x86_64-unknown-linux-gnu > > (from $CONFIG_SITE, set by /etc/profile.d/site.sh) which sets a libdir > > that ends in /lib64 rather than /lib if it finds that t

bug#11302: Automake 1.11d on openSUSE 12.1

2012-04-22 Thread Bruno Haible
Hi Stefano, > > FAIL: t/depcomp2 > > > > > > [SNIP] > > ... > > The file 'stderr' is not empty: It contains this two-line warning > > > > configure: WARNING: if you wanted to set the --build type, don't use > > --host. > > If a cross compiler is detected then cross compi

bug#11306: Automake 1.11d on MacOS X

2012-04-21 Thread Bruno Haible
> The beta release "1.11d" of Automake is now available at > . On MacOS X 10.5, with Autoconf 2.65: 6 tests fail. FAIL: t/lex-libobj.sh FAIL: t/parallel-am.sh FAIL: t/parallel-am2.sh FAIL: t/parallel-am3.sh FAIL: t/tap-summary-color.sh FAIL: t/werror3.sh Detail

bug#11093: [platform-testers] Automake 1.11.3b test release

2012-04-21 Thread Bruno Haible
Hi Stefano, > How to reproduce: > 1. Unpack automake-1.11d.tar.gz > 2. patch -p1 < > .../0001-vala-configure-exit-with-status-77-not-1-if-valac-ve.patch > 3. ./configure > 4. make I managed to work around this. The patch indeed causes the tests to be skipped, leading to: ... PASS: t/vala.sh val

bug#11302: Automake 1.11d on openSUSE 12.1

2012-04-21 Thread Bruno Haible
Stefano Lattarini wrote: > The beta release "1.11d" of Automake is now available at > . On openSUSE 12.1 x86_64: 9 tests failed. FAIL: t/depcomp2.sh FAIL: t/posixsubst-libraries.sh FAIL: t/posixsubst-ltlibraries.sh FAIL: t/posixsubst-scripts.sh FAIL: t/tap-summa

bug#11093: [platform-testers] Automake 1.11.3b test release

2012-04-21 Thread Bruno Haible
Stefano Lattarini wrote: > I think that the best fix would be to improve AM_PROG_VALAC to exit > with status '77' instead of '1' if the vala compiler found is too old; > so, what about the attached patch? Most importantly, would it fix > the failures you are seeing? The patch you sent does not ap

bug#11093: [platform-testers] Automake 1.11.3b test release

2012-04-21 Thread Bruno Haible
Hi Stefano, In Automake 1.11.3b I reported these: > > FAIL: vala-vpath.test > > FAIL: vala-mix.test > > FAIL: vala-mix2.test > > > [SNIP] > ... > > Looking at git://git.gnome.org/vala it is clear that the option --profile > > was added on 2009-05-08, in version 0.7.3. The autoconf test reported >

bug#11093: [platform-testers] Automake 1.11.3b test release

2012-03-25 Thread Bruno Haible
> Testing with Cygwin, MSYS/MinGW, MacOS X, and proprietary UNIX systems > (e.g., AIX, IRIX, older Solaris) would be greatly appreciated. On MacOS X 10.5: All tests passed. On Linux (openSUSE 12.1): FAIL: conffile-leading-dot.test FAIL: vala-vpath.test FAIL: vala-mix.test FAIL: vala-mix2.test F

bug#10324: [Platform-testers] Automake 1.11.1b test release

2012-01-08 Thread Bruno Haible
Hi Peter, You wrote in : > Oh crap, you are crossing over from Cygwin without telling the build > system, right? Or what is your $build if you don't specify --host? > I should have known that, given that it was you... I expect

bug#10324: [Platform-testers] Automake 1.11.1b test release

2012-01-06 Thread Bruno Haible
Hi Stefano, Replying to : >> * Linux/PowerPC 64-bit >> >> FAIL: silent-many-generic.test >> >> Find attached the log file. I configured Automake with >> CC="gcc -m64"; export CC; >> CXX="g++ -m64"; export CXX; >> CPPFLAGS="-

bug#10426: 3 of 872 tests failed on openSUSE 12.1

2012-01-03 Thread Bruno Haible
Stefano Lattarini wrote: > # We pass '--libdir' explicitly, to avoid spurious failures due to users > # or distributions possibly overriding '${libdir}' in their $CONFIG_SITE > # file (for example, defining it to '${prefix}/lib64' on 64-bit systems, > # as is the case with OpenSUSE 12.1).

bug#10426: 3 of 872 tests failed on openSUSE 12.1

2012-01-03 Thread Bruno Haible
Hi Stefano, > > FAIL: pr300-lib.test (exit: 1) > > == > Uh? Where us this `lib64' coming from? Have you maybe overriden `${libdir}' > in your `config.site' file? > > The failure here is being caused by the fact that the libraries are apparently > being installed i

bug#10426: 3 of 872 tests failed on openSUSE 12.1

2012-01-02 Thread Bruno Haible
Hi, On openSUSE 12.1 system, installation of automake 1.11.2 fails: FAIL: instfail.test FAIL: pr300-lib.test FAIL: pr300-ltlib.test = 3 of 872 tests failed (39 tests were not run) See tests/test-suite.log Please report to bug-automake@gnu.org =

bug#9026: Supporting $ACLOCAL_PATH?

2011-07-08 Thread Bruno Haible
ention in the GNU gettext documentation. I wasn't aware of it up to now. 2011-07-08 Bruno Haible * gettext.texi (aclocal): Recommend the use of aclocal's --install option. Suggested by Stefano Lattarini . --- gettext-tools/doc/gettext.texi.orig Fri Jul 8 23:2

bug#9026: Supporting $ACLOCAL_PATH?

2011-07-08 Thread Bruno Haible
Hi Stefano, > I say we should instead follow the UNIX practice of giving the user enough > rope to hang himself, but advise him not to do so This is a good attitude for the many features with which a developer can only harm himself and which cause no harm to others. But with $ACLOCAL_PATH he can

bug#9026: Supporting $ACLOCAL_PATH?

2011-07-08 Thread Bruno Haible
Ludovic Courtès wrote: > ... having a reproducible way of > producing tarballs, and user-specific environment settings appear to go > counter this goal. Not only that. Also, it is important for distributors to be able to regenerate the 'configure' file of packages, for a variety of reasons. They c

bug#8881: config.h double inclusion

2011-06-17 Thread Bruno Haible
Alfred M. Szmidt wrote: > > > I think that autoconf should have the guard for double inclusion. > > > > Autoconf does not need to provide a double-inclusion guard for > > config.h, because those packages that need it can get it through > > use of AH_TOP and AH_BOTTOM. > > That is not a rea

bug#8718: error when using nested conditionals

2011-06-17 Thread Bruno Haible
Ralf Wildenhues wrote: > Please note that this does have a small change in semantics, namely if > there is code using AM_COND_IF Thanks for the heads-up; I'll change the code to handle that as well. > > There's no point in being _that_ safe that you check unused expressions > > for validity. C co

bug#8718: error when using nested conditionals

2011-06-17 Thread Bruno Haible
Hi Ralf, > More danger ahead: > > if $foo; then result=ok; else result=bad; fi > AM_CONDITIONAL([COND1], [test $result = ok]) > if $bar; then result=ok; else result=bad; fi > AM_CONDITIONAL([COND2], [test $result = ok]) > > I've seen such code in third party projects, it will break if you delay

bug#8881: config.h double inclusion

2011-06-16 Thread Bruno Haible
Alfred M. Szmidt wrote: > I think that autoconf should have the guard for double inclusion. Autoconf does not need to provide a double-inclusion guard for config.h, because those packages that need it can get it through use of AH_TOP and AH_BOTTOM. Bruno -- In memoriam Imre Nagy

bug#8718: error when using nested conditionals

2011-06-16 Thread Bruno Haible
Hello Ralf, > > === foo.m4 > > > > AC_DEFUN([gl_FOO], > > [ > > if test 7 = 7; then > > use_variant_a=true > > else > > use_variant_a=false > > fi > > AM_CONDITIONAL([USE_VARIANT_A], [$use_variant_a]) > > Instea

bug#8718: error when using nested conditionals

2011-06-10 Thread Bruno Haible
Peter, > how about the following alternative (for all conditionals, or just for some > of them, e.g., those under the regime of AM_IGNORE_UNDEFINED_CONDITIONALS): > Replace the AC_MSG_ERROR() above by a warning and set both $1_TRUE and > $1_FALSE to something that, when not hidden in a false branc

bug#8718: error when using nested conditionals

2011-06-10 Thread Bruno Haible
> Since the usual way to implement nestable behaviour in Autoconf is > m4_pushdef / m4_popdef Another idea would to be m4_pushdef AM_CONDITIONAL itself. If you add a third parameter to AM_CONDITIONAL, denoting the conditions in which the conditional needs to be defined, then gnulib could emit cod

bug#8718: error when using nested conditionals

2011-06-10 Thread Bruno Haible
Jack Kelly wrote: > AM_IGNORE_UNDEFINED_CONDITIONALS(REGEX) ignores > "undefined-conditional" errors for conditions that match REGEX. With this proposal, gnulib would have to turn off all "undefined-conditional" errors, that is, use a regex of [.*]. That's because as exemplified in the previous ma

bug#8718: error when using nested conditionals

2011-06-10 Thread Bruno Haible
Hi Stefano, > 'AM_IGNORE_UNDEFINED_CONDITIONALS' can accept two > arguments, "yes" and "no" (defaulting to "yes" if no argument is given). > The idea is that an usage like: > > AM_CONDITIONAL([FOO], [:]) > AM_IGNORE_UNDEFINED_CONDITIONALS([yes]) > if test -n "$user_flag"; then > AM_CON

bug#8718: error when using nested conditionals

2011-06-09 Thread Bruno Haible
Hi Stefano, > Cannot you simply initialize the > automake conditionals you might need and that you know might be called > conditionally to (possibly dummy) defaults in gl_INIT or gl_EARLY or > something like that? No, I cannot do that. The gnulib users write code like this:

bug#8718: error when using nested conditionals

2011-05-22 Thread Bruno Haible
Hi, When a Makefile.am has nested conditionals, then when an inner conditional is not defined _and_ not needed (because it's in an unused part of the Makefile.am), then 'configure' nevertheless emits a fatal error. This causes major problems for the new 'conditional-dependencies' mode of gnulib-t

bug#8473: depcomp bug with HP-UX cc and VPATH build

2011-04-10 Thread Bruno Haible
Hi, The dependencies mechanism of Automake leads to a compilation failure when used in a VPATH build (with GNU make, of course) and HP-UX cc. The failure occurs during the third command of this command sequence: $ gmake $ gmake clean $ gmake ... gmake[4]: Entering directory `/tmp/testdir

bug#7621: add a way to pass link dependencies

2011-01-22 Thread Bruno Haible
Hello Ralf, Thank you for taking care of this long-standing problem. > implement both (A) and (B), but in the latter > let $(prog_LIBS) override $(LIBS) instead of having both. For (A), the list of options to be ignored during dependency extraction is the following (cf. gnulib/build-aux/config.r

bug#7621: add a way to pass link dependencies

2010-12-12 Thread Bruno Haible
Hi, When creating an executable or library, sometimes other libraries have to be mentioned on the link command line as dependencies. For dependencies inside the build tree, Automake handles this fine, through the _LDADD variable for executables and the _LIBADD variable for libraries. See e.g. the

doc: misplaced sections about Emacs Lisp, Java, Python

2010-08-15 Thread Bruno Haible
Hi, In the Automake documentation, the sections "Emacs Lisp", "Java", "Python" are in a chapter "Other GNU Tools", two chapters away from the sections "C++ support", "Objective C Support", "Assembly Support", "Java Support". It is somewhat confusing. Suggestion: - Move the sections "Emacs Lisp"

[PATCH] Don't hide the table of contents

2010-08-15 Thread Bruno Haible
it nicely: It puts a hierarchical table of contents at the beginning. Here is a suggestion to do the same in the Automake manual. 2010-08-15 Bruno Haible Don't hide the table of contents. * doc/automake.texi: Move the table of contents to the beginning. --- doc

Re: ‘libunistring’ module errors

2010-06-05 Thread Bruno Haible
[ dropping bug-gnulib ] Hi Ralf, > I'm fairly sure aclocal does this out of > necessity, i.e., it might lead to disaster if it were to trace an > unknown, possibly conflicting set of macro files. (The other > possibility why it was done this way is efficiency.) Yes, I agree. I wouldn't change t

internal error in aclocal

2010-06-03 Thread Bruno Haible
Hi, The 'aclocal' program asked me to report this. I'm using automake 1.11.1, autoconf 2.65, m4 1.4.14. How to reproduce: $ wget http://www.haible.de/bruno/gnu/automake-bug-20100603.tar.gz $ tar xvfz automake-bug-20100603.tar.gz $ cd automake-bug-20100603 $ aclocal -I m4 Result: aclocal: #

Re: AC_LIBOBJ with file in subdirectory does not work

2010-05-27 Thread Bruno Haible
Hi Ralf, > > - How to use Automake conditionals or AC_SUBSTed variables without > > file names as replacement for AC_LIBOBJ. > > That's fine only for projects where the list of libobjs is taken from a > static list of file names. Thus it may be fine for gnulib, but it is > not something we

Re: AC_LIBOBJ with file in subdirectory does not work

2010-05-26 Thread Bruno Haible
Hi Ralf, > Can you please tell me how to reproduce that hell in libgettextpo? You reproduced it already pretty well. > +# Ensure objects in ../src are renamed so they don't conflict with > +# the objects generated from ../src/Makefile. > +libgettextpo_la_CPPFLAGS = $(AM_CPPFLAGS) Wow. What a ha

Re: AC_LIBOBJ with file in subdirectory does not work

2010-05-26 Thread Bruno Haible
Hi Ralf, > Can you please tell me how to reproduce that hell in libgettextpo? You already reproduced it pretty well. > I tried the patch below, and so far it seems to work reasonably well. > You lose the ability to do 'make clean' in either of > gettext-tools/libgettextpo and gettext-tools/src w

Re: AC_LIBOBJ with file in subdirectory does not work

2010-05-25 Thread Bruno Haible
[Adding bug-autoconf. This is a reply to .] Hi Ralf, > Autoconf code knows nothing about the Automake subdir-objects option > (and what's more, that option may vary between different Makefile.am > files). Exactly, that's the main s

Re: AC_LIBOBJ with file in subdirectory does not work

2010-05-25 Thread Bruno Haible
PS: The challenge is to get AC_LIBOBJ working - with and without the 'subdir-objects' option, - for object files in executables, .a libraries, and .la libtool libraries. In all 6 situations. Bruno

AC_LIBOBJ with file in subdirectory does not work

2010-05-24 Thread Bruno Haible
Hi, When AC_LIBOBJ is used with a source file in a subdirectory, no problem from autoconf's side, but a fatal error from automake occurs. I'm using autoconf 2.65, automake 1.11.1. How to reproduce: 1) Create a fresh empty directory. $ mkdir -p foo build-aux 2) Save these three files:

stamp-vti and OpenBSD make

2010-05-15 Thread Bruno Haible
Hi, I'm trying to build a slightly modified libunistring-0.9.3 on OpenBSD 4.5. With GNU make, there is no problem. But with /usr/bin/make, I get this error: $ wget http://www.haible.de/bruno/gnu/libunistring-0.9.3a.tar.gz [This tarball was generated with automake's "make distcheck" rule.]

Re: copyright statement

2010-02-07 Thread Bruno Haible
Simon Josefsson wrote on 2010-01-27: > Oops! Here is a patch against automake, we can sync it to gnupload once > this has been applied. > > /Simon > > diff --git a/lib/gnupload b/lib/gnupload > index bd120e8..f8bf2b8 100755 > --- a/lib/gnupload > +++ b/lib/gnupload > @@ -1,9 +1,10 @@ > #!/bin/s

Re: missing warning about absence of AM_PROG_CC_C_O

2009-10-06 Thread Bruno Haible
Hello Ralf, > missing AM_PROG_CC_C_O has been turned into a portability warning > in 1.10. -Wportability should be on by default in 1.10 and newer unless > you use the 'foreign' option. You should thus see it as soon as you add > -Wportability to AUTOMAKE_OPTIONS in gltests/Makefile.am. > ... >

missing warning about absence of AM_PROG_CC_C_O

2009-10-03 Thread Bruno Haible
Hi, Here is a situation where automake 1.9.6 errs out because of a missing invocation of AM_PROG_CC_C_O in a configure.ac, but automake >= 1.10 don't err out any more and instead produces a Makefile.in that fails when the C compiler does not support -c and -o in the same command line. How to repr

'compile' script calls mv in a way that fails

2009-10-03 Thread Bruno Haible
dir3/build-aux/compile /tmp/oldcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -c -o localcharset.o localcharset.c mv: `localcharset.o' and `localcharset.o' are the same file When GNU mv produces this error message, it also errs out with exit code 1. Here is a proposed patch (tested): 2009-10-03

Re: pointless 'aclocal' warning

2009-08-09 Thread Bruno Haible
Ralf Wildenhues wrote on 2009-05-11: > > In the automake HEAD from today, but *not* in automake-1.10.2, this code > > in a .m4 file > > > > m4_ifdef([AM_XGETTEXT_OPTION], > > [AM_XGETTEXT_OPTION([--flag=error:3:c-format]) > > AM_XGETTEXT_OPTION([--flag=error_at_line:5:c-format])]) > >

Re: AM_SILENT_RULES has no effect

2009-05-22 Thread Bruno Haible
Ralf Wildenhues wrote: > Try not setting `silent-rules' in Makefile.am at all. It is sufficient > to only use the macro AM_SILENT_RULES in configure.ac. > > The setting in Makefile.am has been turned into an error So there's definitely two things to fix: 1) The error message is misleading. It is

AM_SILENT_RULES has no effect

2009-05-21 Thread Bruno Haible
Hi, The automake 1.11 documentation says that to enable silent rules: "The developer needs to do either of the following: * Add the `silent-rules' option as argument to `AM_INIT_AUTOMAKE'. * Call the `AM_SILENT_RULES' macro from within the `configure.ac'

pointless 'aclocal' warning

2009-05-10 Thread Bruno Haible
Hi, In the automake HEAD from today, but *not* in automake-1.10.2, this code in a .m4 file m4_ifdef([AM_XGETTEXT_OPTION], [AM_XGETTEXT_OPTION([--flag=error:3:c-format]) AM_XGETTEXT_OPTION([--flag=error_at_line:5:c-format])]) triggers an 'aclocal' warning: gnulib-m4/gnulib-comp.m4:176

Re: dvi, pdf rules: incorrect invocation of texi2dvi, texi2pdf

2009-04-07 Thread Bruno Haible
e default search path of the TeX distribution". That's a bug in texi2dvi, IMO. Indeed, the attached patch fixes the problem. For texinfo, this is only half of the required work. The other half should be to add a unit test against this bug. For automake, the workaround is simple: Add

dvi, pdf rules: incorrect invocation of texi2dvi, texi2pdf

2009-04-07 Thread Bruno Haible
Hi, Automake generates rules for creating DVI and PDF formatted documentation that rely on the TEXINPUTS variable. This variable appears to have not the desired effect in recent TeX distributions. How to reproduce: - Install texinfo 4.13 in your PATH. - Unpack GNU hello 2.4. $ ./configure - Get

Re: mostlyclean and texinfo outputs (was: Installing gnulib from git)

2009-04-03 Thread Bruno Haible
Hi Ralf, Thanks for pursuing this. > > For the {dvi,ps} formats this is (arguably) a bug in automake, > > I agree; automake should remove {html,dvi,ps,pdf} only upon 'clean', but > not upon 'mostlyclean'. Only the latex by-products should be removed > upon 'mostlyclean'. OK, this is issue #1.

Re: Serial number formats

2009-03-22 Thread Bruno Haible
Hello Ralf, > A compromise achieved after discussion on this (the bug-gnulib) list: > Oh, I withdraw my criticism. Alexandre researched well, and asked on the right list. Sadly, I was sleeping throughout the duration of this thr

Re: Serial number formats

2009-03-20 Thread Bruno Haible
Ralf Wildenhues asked: > What exactly is the point of using a different format and extraction > code than aclocal does? ... > Gettext is using a format slightly incompatible to the aclocal one here, aclocal exploits '# serial' lines since 2005-02-01. Gettext is using the format that you call "slig

Re: Serial number formats

2009-03-20 Thread Bruno Haible
Colin Watson wrote: > How about the attached patch to autopoint which causes it to look > through all m4 directories in ACLOCAL_AMFLAGS and compare serial > numbers? That would avoid the problem of 'make dist' forgetting to ship > files even if you do use multiple m4 directories; the files will sim

install-man3 target install manual pages under wrong names

2009-03-18 Thread Bruno Haible
Hi, The automake-generated 'install-man[2-79] targets apply $(transform), that it, the program name transformation, to the base name of manual pages before installing them. This is wrong, because the program name transformation has no effect on function names defined by libraries. It should only a

Re: Serial number formats

2009-03-16 Thread Bruno Haible
Colin Watson wrote: > I would find it more elegant to install all the files separately and > have a defined ordering between them It may work for you. For the general developer, I think it opens too many pitfalls (missing -I options, confusion about which file is used, possibly empty directories a

Re: Serial number formats

2009-03-16 Thread Bruno Haible
Eric Blake wrote: > Maybe the solution is to expand automake's list of valid serial lines. > True, it won't help until after the next Automake release, but if there > are enough files in the wild that use '# file.m4 serial n', it seems like > we should make it a valid format rather than forcing all

hello 2.3: installation failure on MacOS X 10.5

2008-04-06 Thread Bruno Haible
Hi, hello-2.3 does not install correctly on MacOS X 10.5, when GNU coreutils are not installed. $ export PATH=.:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/X11R6/bin $ ./configure --prefix=$HOME/data/local-macos ... $ make ... $ make install Making install in contrib make[2]:

Re: ABOUT-NLS

2008-03-24 Thread Bruno Haible
Micah Cowan wrote in : > > Automake complains/dies if ABOUT-NLS is missing from packages > > that use GNU gettext. > > > > However, the ABOUT-NLS file contains much content that assumes > > the package includes gettext (libintl).

Re: RFE: make automake's output deterministic

2008-01-07 Thread Bruno Haible
Hello Ralf, > Thanks for the bug report, and a Happy New Year. Thank you for processing it, and a happy and productive 2008. > The patch below should do the trick, I think. Yes, confirmed. Thanks! > It would be nice to have > a test to expose this to go along with this change if possible. Can

  1   2   >