bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

a Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Tue, 30 Apr 2024 09:59:58 +0200 Subject: [PATCH] doc: update Vala documentation * Update the URL for Vala. * Drop the mention of a version requirement, as no current system will have a too-old version of Vala. * Note the restriction on condition

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

On Sat, 27 Apr 2024 at 20:36, Reuben Thomas wrote: > On Sat, 27 Apr 2024 at 00:53, Karl Berry wrote: > >> Reuben, any chance you can whomp up a test for this patch? >> > > No problem, I will do this when I can find a moment. Since I don't > actually need this fix aft

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

On Sat, 27 Apr 2024 at 00:53, Karl Berry wrote: > Reuben, any chance you can whomp up a test for this patch? > No problem, I will do this when I can find a moment. Since I don't actually need this fix after all, it may not be quick! -- https://rrt.sc3d.org

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

On Wed, 24 Apr 2024 at 23:38, Reuben Thomas wrote: > Apologies, I should have run the tests before posting the patch. Indeed, I > have broken things. So, please consider the documentation patch, and I'll > take another look at the bug-fix (which in any case I have also realised > do

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

On Wed, 24 Apr 2024 at 22:57, Reuben Thomas wrote: > > The patch is trivial, so hopefully it's obvious if there's a problem for > some reason! I hope I explained well enough what problem I'm trying to > solve. > Apologies, I should have run the tests before posting the patch.

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

enough what problem I'm trying to solve. -- https://rrt.sc3d.org From 490777db71c2086cfbd3ec359fceca5fc853047d Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Wed, 24 Apr 2024 22:41:48 +0200 Subject: [PATCH 2/2] vala: do not build Vala sources excluded by automake conditionals MIME-Version: 1.0

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Sat, 9 Dec 2023 at 15:16, Reuben Thomas wrote: > > If you're happy with that, I'll write a patch. > Patch attached. -- https://rrt.sc3d.org From 06f6765b7d10132d0dcefde1265b4d5f01df76b4 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Sat, 9 Dec 2023 15:20:44 +0200 Subject: [P

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Sat, 9 Dec 2023 at 00:03, Karl Berry wrote: > The manual currently says: "You should never explicitly mention the > intermediate (C or C++) file in any `SOURCES' variable; only list > the source file." > > I don't know the code here, and this probably wasn't the question, but I >

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Wed, 6 Dec 2023 at 23:59, Karl Berry wrote: > Any chance that one of you could write a patch for the manual to explain > whatever needs to be explained (better)? --thanks, karl. > I'd happily do that if I could work out, or someone could explain, exactly what's going on here. The manual

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Sun, 3 Dec 2023 at 03:47, Mike Frysinger wrote: > > > > I think I've worked it out: I need to add the .c file that is generated > > from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing > that > > fixes the problem. > > we prob could add a .y/.l example to the manual. i think

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Wed, 12 Apr 2023 at 17:59, Reuben Thomas wrote: > On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote: > >> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do >> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures >> sometimes: >

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote: > I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do > a parallel build (in my case, MAKEFLAGS=-j4), I get build failures > sometimes: > In fact, I don't need to do a parallel build, just build serially from

bug#62791: BUILT_SOURCES not honoured in parallel build?

I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do a parallel build (in my case, MAKEFLAGS=-j4), I get build failures sometimes: $ make all make all-am make[1]: Entering directory '/home/rrt/.local/var/repo/a2ps/src' YACC parsessh.c CC libparse_a-lexssh.o

bug#61278: Automake warns about LDFLAGS for defined library

On Sun, 5 Feb 2023 at 06:09, Nick Bowler wrote: > > What Automake is trying to tell you is that LDFLAGS is meaningless > on a static library. This message could definitely be improved! > Of course, thanks! I was confused because in another Makefile.am that had only a static library I did not

bug#61278: Automake warns about LDFLAGS for defined library

Using automake 1.16.5, in my Makefile.am, I have the following lines: noinst_LTLIBRARIES = liba2ps.la liba2ps_la_LDFLAGS = $(LIBGC_LIBS) liba2ps_la_SOURCES = $(liba2pssources) $(libitsources) $(mylibitsources) liba2ps_la_LIBADD = ../lib/libgnu.la $(LIBINTL) $(LIBSOCKET) $(GETHOSTNAME_LIB)

bug#61088: Problem solved

I found the "Rules-*" feature of gettext to do this; sorry for the noise! -- https://rrt.sc3d.org

bug#61088: How to make AM_EXTRA_RECURSIVE_TARGETS skip some directories?

I have an automake project with a 'po' subdirectory whose contents, including Makefile.in.in, is entirely generated by gettext. 'po' is in my top level Makefile.am's SUBDIRS. When I add an AM_EXTRA_RECURSIVE_TARGETS entry, say 'foo', automake tries to recurse into po and 'make foo', and of course

bug#60607: Making dvi target do nothing

On Sun, 8 Jan 2023 at 00:23, Karl Berry wrote: > How does this change to the doc look? --thanks, karl. > Thanks for this Karl; it certainly fixes the problem I had! (I'll leave the assessment of technical accuracy to others.) -- https://rrt.sc3d.org

bug#60607: Making dvi target do nothing

On Sat, 7 Jan 2023 at 08:46, Nick Bowler wrote: > > This example in the manual is talking about writing a custom > Makefile, *without* using Automake, that you want to recurse > into using Automake's SUBDIRS feature. > Aha! Thanks for pointing this out. I think the manual is misleading in

bug#60607: Making dvi target do nothing

I'm using automake 1.16.5. The advice about how to disable the "dvi" target doesn't seem to work. In the manual it says: To make ‘dvi’ into a do-nothing target, see the example for ‘EMPTY_AUTOMAKE_TARGETS’ in *note Third-Party Makefiles::. If I have: EMPTY_AUTOMAKE_TARGETS = dvi .PHONY:

bug#45013: Using a different tags program

On Thu, 3 Dec 2020 at 22:26, Reuben Thomas wrote: > > Happy to look into it. > I have looked into it and attach a trivial patch, which works nicely. It's not obvious to me whether any documentation is required; I rather expected that these variables would behave like others (CC

bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

On Fri, 4 Dec 2020 at 22:20, Karl Berry wrote: > You sent the proposed change in the bug report to Bruno, so I committed > it in your name. > Sorry, I didn't mean to say I had nothing to do with the contents of the patch, just that I didn't have anything to do with installing it. (And I wasn't

bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

I just noticed while updating to look at something else that a version of my patch seems to have been applied, but with a misleading commit message. It has my name on it, commit 7581ec208. But I don't think I had anything to do with that commit! The commit log says: "reverse -newer test". But it

bug#45013: Using a different tags program

On Thu, 3 Dec 2020 at 22:17, Karl Berry wrote: > Hi Reuben, > > There doesn't seem to be a way for the user to configure a different > ctags program > > I don't know of anything to the contrary. So ... would you be up for > making a patch to support it :)? Etags too, I guess? At least

bug#45013: Using a different tags program

There doesn't seem to be a way for the user to configure a different ctags program, unless I'm overlooking something? Passing "CTAGS=foo" to configure has no effect; it seems that all one can do is pass "CTAGS=foo" to make every time one runs "make tags". -- https://rrt.sc3d.org

bug#44845: Typo in manual

The example filename "zardoc.c" in the Vala section should be "zardoz.c"; it doesn't really matter, but it is almost certainly a typo. -- https://rrt.sc3d.org

bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

On Sat, 21 Nov 2020 at 22:01, Karl Berry wrote: > > By the way, I don't think that find command (or the cp -p for that > matter) is excessively portable. But I guess we don't much care about > crufty systems for vala support. --thanks, karl. > They are both using only POSIX-2008 features; these

bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

[CCing the bug, though this email wasn't addressed to it; looks like it should have been, though!] Indeed, the generated C file shouldn't be rebuilt; the existing distributed C source file should be used. I tried the test with v1.16.3 and it passed for me. Looking at the logs, I found this line

bug#44458: Regenerating testsuite-part.am when a new test case is added

Or, bug #11347 again. I just spent quite a while chasing down a test failure that was due to testsuite-part.am not being remade when new tests were added. I duly found bug #11347, which contains a rationale for not having testsuite-part.am depend on all the tests. However, the rationale doesn't

bug#13002: Updated, fixed patch

On Fri, 30 Oct 2020 at 01:45, Karl Berry wrote: > install an acceptable version of my patch, as it improves the status > quo, and include it in the next release. Then I'd think about > whether it's possible to redo the Vala support entirely. > > Sounds sensible. > > I applied your

bug#13002: Updated, fixed patch

To follow up clearly: if it were up to me, I'd install an acceptable version of my patch, as it improves the status quo, and include it in the next release. Then I'd think about whether it's possible to redo the Vala support entirely. -- https://rrt.sc3d.org

bug#13002: Updated, fixed patch

On Wed, 28 Oct 2020 at 20:37, Karl Berry wrote: > > As I wrote before, I strongly support this approach. Since the C file is > derived, don't distribute it. Would that simplify the patch? > A patch to re-do Vala support would be a larger patch at this stage, though overall it would certainly

bug#13002: Updated, fixed patch

to continue. -- https://rrt.sc3d.org From 603373be839a87cb0ee97a16f4a243d86bbae72e Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Wed, 28 Oct 2020 09:42:21 + Subject: [PATCH] Improve Vala support (closes #13002) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer

bug#13002: Dealing with C intermediate files

I've had a look at the patch now, and found and fixed one bug. However, an issue comes up for VPATH builds that needs a more thorough fix: C files generated from Vala sources are shipped by "make dist" and hence end up in srcdir, but in a VPATH build with a Vala compiler, they will be in

bug#44129: Patch to improve valac version detection

error message in case of failure. From 0b6fecf316b7293b7ea66fbcdeb9f713dcdab4e1 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Wed, 21 Oct 2020 23:31:46 +0100 Subject: [PATCH] Improve Vala compiler detection: use API version, not compiler version * m4/vala.m4: check `valac --api-version

bug#44129: Patch to improve valac version detection

sion 0.52 ) -- https://rrt.sc3d.org From 3cb4252dd8e182bab5f484d3a8dd7a96f6da2180 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Wed, 21 Oct 2020 23:31:46 +0100 Subject: [PATCH] Improve Vala compiler detection: use API version, not compiler version * m4/vala.m4: check `valac --api-ver

bug#44010: Per-compilation C files

On Thu, 15 Oct 2020 at 22:09, Karl Berry wrote: > > I found some long-ago patches (not for this particular issue) from a > previous contributor (Daniel Espinosa), which surely worked at the time > they were written, but now break things. And Daniel stopped replying to > my mail. Sorry to be so

bug#44010: Per-compilation C files

I'm sorry, I see this question is covered in the manual: Note that currently, you cannot use per-target ‘*_VALAFLAGS’ (*note > Renamed Objects::) to produce different C files from one Vala source > file. > Feel free to close this issue!

bug#44010: Per-compilation C files

On Thu, 15 Oct 2020 at 13:06, Reuben Thomas wrote: > I've recently started using automake with Vala; it works very well! I'm > particularly impressed that the "make dist" rules include the C files, so > that the builder doesn't need a Vala compiler. > > There's one nit

bug#44011: Improvements to contrib/README

I attach a patch relative to current git that improves contrib/README. -- https://rrt.sc3d.org From 759746989cc75c2a929c09b28226d9be18d64a21 Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Thu, 15 Oct 2020 13:11:11 +0100 Subject: [PATCH] contrib/README: fix and clarify the English

bug#44010: Per-compilation C files

I've recently started using automake with Vala; it works very well! I'm particularly impressed that the "make dist" rules include the C files, so that the builder doesn't need a Vala compiler. There's one nit: I want to make multiple .c files from the same .vala file, analogous to the way that

bug#31157: Advice for help2man does not work for parallel builds

On 21 April 2018 at 16:13, Mathieu Lirzin <m...@gnu.org> wrote: > Hello Reuben, > > Reuben Thomas <r...@sc3d.org> writes: > > > In the manual, we are given the following pattern for using help2man > > without breaking make distcheck: > > > > fo

bug#31157: Advice for help2man does not work for parallel builds

In the manual, we are given the following pattern for using help2man without breaking make distcheck: foo.1: foo.c $(top_srcdir)/configure.ac $(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT) help2man --output=foo.1 ./foo$(EXEEXT) The problem is that with make -j this can

bug#25413: Trivial typo in automake.texi

I just noticed, and still present in git: requited → required -- http://rrt.sc3d.org

bug#23521: XFAIL

On 20 May 2016 at 15:58, Gavin Smith wrote: > On 19 May 2016 at 00:04, Mathieu Lirzin wrote: > >> It is often easier to write expected-to-fail tests this way (so that > >> they can all look the same), rather than have to have, for example, an > >> extra

bug#23521: XFAIL

On 19 May 2016 at 00:55, Peter Johansson wrote: > > > On 05/19/2016 09:04 AM, Mathieu Lirzin wrote: > >> Another common use for "expected failure" is to write tests to check >>> >that error conditions arise as expected, for example, by checking that >>> >a program raises an

bug#23521: XFAIL

On 19 May 2016 at 00:04, Mathieu Lirzin wrote: > > It is often easier to write expected-to-fail tests this way (so that > > they can all look the same), rather than have to have, for example, an > > extra driver that converts expected errors into success codes for the > > automake

bug#23521: XFAIL

The documentation says: "It's not uncommon, especially during early development stages, that some tests fail for known reasons, and that the developer doesn't want to tackle these failures immediately (this is especially true when the failing tests deal with corner cases)." Another common use for

bug#16997: Typo in @pxref in manual

It's important to note that, differently from what we've seen for the serial test harness (@pxref{Parallel Test Harness}) should presumably be: It's important to note that, differently from what we've seen for the serial test harness (@pxref{Serial Test Harness}) -- http://rrt.sc3d.org

bug#15949: Apparently out-of-date warning

On 29 December 2013 22:24, Stefano Lattarini stefano.lattar...@gmail.comwrote: AM_PROG_AR is only required for people interested in having their package buildable with Microsoft tools And we can't make AM_PROG_AR an automatic default? What would be the downside? (Sorry if I'm being a pain,

bug#15949: Apparently out-of-date warning

On 26 December 2013 15:39, Stefano Lattarini stefano.lattar...@gmail.comwrote: But AM_PROG_AR truly does not define $RANLIB itself. Perhaps you are using libtool and calling AC_PROG_LIBTOOL or LT_INIT? Probably. So, how about changing the sentence from should to may need, or is there some

bug#10227: Python installation fails for Python 3

On 22 November 2012 13:01, Stefano Lattarini stefano.lattar...@gmail.comwrote: OK, thanks for explaining it once again. I can now reproduce the same issue on Debian. I think this is something we should try to work around, since we cannot have our installation rules broken by default on both

bug#12620: Parallel tests vs fast tests (and beyond)

On 11 October 2012 22:12, Jack Kelly j...@jackkelly.name wrote: We had a discussion along these lines when refactoring elisp compilation: in the past it was all done in one big batch. Now it's done with an emacs invocation per .el file. The result of that discussion was that while you slow

bug#12620: Parallel tests vs fast tests (and beyond)

With the recent work on parallel tests in automake I thought it was time to give them a spin, so I did, for the zee branch of GNU Zile. This has about 100 tests, the total wall clock time being around 8s on my 2.5GHz 4-core Sandy Bridge machine, with the following target: check-local:

bug#12516: Typo in automake.texi

expending → expanding Checked in current git HEAD. -- http://rrt.sc3d.org

bug#11863: Building test plugins

On 5 July 2012 07:19, Gary V. Vaughan g...@gnu.org wrote: Currently the best way to tell Automake to only build a libtool library for `make check' without installing it, but at the same time to tell libtool not to make a convenience archive is: check_LTLIBRARIES += tests/libalientest.la

bug#11863: Building test plugins

I have a library that I want to build just for tests. Hence, I add it to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or whatever) to be built, but it isn't! If I instead add the library to pkglib_LTLIBRARIES, then the shared object is built, but the test library is installed,

bug#11863: Building test plugins

On 4 July 2012 23:35, Stefano Lattarini stefano.lattar...@gmail.com wrote: tags 11863 + moreinfo thanks On 07/04/2012 10:43 PM, Reuben Thomas wrote: I have a library that I want to build just for tests. Hence, I add it to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll

bug#10226: Drop redundant Python 1.5 support?

an unhelpful MIME type (hence my originally sending it inline). -- http://rrt.sc3d.org From 159eee8f676f41aa4619d074e2bb8a01d102e4a8 Mon Sep 17 00:00:00 2001 From: Reuben Thomas r...@sc3d.org Date: Mon, 5 Dec 2011 23:40:48 +0100 Subject: [PATCH] Remove Python 1.5 support. --- m4/python.m4 | 14

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 22 November 2011 15:50, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: It would be useful to enumerate the user-visible benefits if Automake can depend on using GNU make.  Otherwise it is difficult to do a cost/benefit analysis from the user perspective.  Can you and others please

Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

On 22 November 2011 20:48, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: It would be quite useful for a FSF project to be spun-up to create an embeddable/small language interpreter and standard library which is capable of efficiently implementing complex make-like functionality

bug#8319: latexmk in automake

I've been working with John Collins to improve latexmk's ability to work with automake (actually, I've been talking, he's done all the work). He's put up a snapshot at: http://www.phys.psu.edu/~collins/latexmk/trial/ together with a test project. Thoughts? Very sensibly, I think, John has

bug#8099: LaTeX and automake

On 2 March 2011 22:13, Reuben Thomas r...@sc3d.org wrote: On 2 March 2011 22:12, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: I just learned about rubber which also aims to deal with latex documents. Have you looked at it yet? No, I will do so. Initial impressions are good: rubber is much

bug#8099: LaTeX and automake

Update: I've written to John to ask about copyright assignment, but discovered in the mean time that there are one or two other authors to talk to. I will see what John says first before considering how to proceed. I have also butchered the current version of latexmk to remove all the

bug#8099: LaTeX and automake

By the way, before getting all excited about programming, maybe I could just write some additional documentation for automake recommending the use of latexmk and giving an example Makefile.am fragment?

bug#8099: LaTeX and automake

On 27 February 2011 06:53, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Anyway, the next step to pursue this would be to think hard about the desired semantics, The tricky part here is that latexmk does its own dependency finding. Hence, in my example rules I only list the root file for each

bug#8099: LaTeX and automake

On 27 February 2011 14:42, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Well yes.  Also, as you already mentioned, latex semantics don't really fit a directed graph where the nodes are files; rather, it needs a more complex diagram of states of sets of files.  I don't think trying to map

bug#8099: LaTeX and automake

I have just been investigating the state of the art for LaTeX support. As far as I can tell there's nothing official; the most official things I can find are some unwritten documentation in the autotoolset manual: http://autotoolset.sourceforge.net/tutorial.html and this project suggestion by

bug#8071: Please rename automake invocation node

This is actually a bug that affects several autotools packages, excluding autoconf, for which it's already fixed: the invocation node is added to the info dir as automake which means that info automake goes to the invocation node, not the Top node. autoconf calls its invocation node

bug#7364: Typo in manual

Script are not distributed by default - Scripts are not distributed by default -- http://rrt.sc3d.org

Re: dist-xz compression level

On 11 April 2010 23:37, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: Yes, compression is useful.  However, the cost of pushing the algorithm close to the limit does incur costs as well.  For many packages, getting 99% of the max in 1/2 the time is a worthy tradeoff. This is similar to

Re: Building prog first

On 23 March 2010 06:03, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello Reuben, * Reuben Thomas wrote on Mon, Mar 22, 2010 at 04:44:17PM CET: 2010/3/22 Russell Shaw: Steffen Dettmer wrote: * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: BTW, execution of built programs

Re: Building prog first

On 23 March 2010 10:15, Steffen Dettmer steffen.dett...@googlemail.com wrote: This illustrates a weirdness of autotools: poor support for installing interpreted languages, and also conversely for build-time compiled programs. Yes, also for coffee-cooking there is poor support only. :-) Sure,

Re: Building prog first

On 23 March 2010 17:15, Alfred M. Szmidt a...@gnu.org wrote:   2010/3/22 Alfred M. Szmidt a...@gnu.org:   If searching is the problem   *Web* searching is the answer, not the problem. It isn't when you are not connected to a network. I usually wait until I am; it often takes me rather

Re: Building prog first

On 23 March 2010 18:12, Alfred M. Szmidt a...@gnu.org wrote: You say that the manuals are poor I said that the indices are poor, specifically at indexing concepts rather than just keywords, function names c., in general. I also said that the manuals in general are excellent. and that it is

Re: Building prog first

2010/3/22 Russell Shaw rjs...@netspace.net.au: Steffen Dettmer wrote: * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: BTW, execution of built programs like this makes your package unsuitable for cross-compilation.  Just so you're aware of that. Not true. automake does not have

Re: Baked-in paths

On 15 March 2010 01:30, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Sun, 14 Mar 2010, Reuben Thomas wrote: I imagine this question has been asked before, but searching the archives, the net and the manual didn't help me with the following: I have a C program which loads some

Baked-in paths

I imagine this question has been asked before, but searching the archives, the net and the manual didn't help me with the following: I have a C program which loads some scripts at runtime. These are stored in datadir (e.g. /usr/local/share/prog). But I also want to be able to run the program from

Reference to `sh-utils' should be to `core-utils'

diff --git a/doc/automake.texi b/doc/automake.texi index b3f4a76..17afa84 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -9203,7 +9203,7 @@ run-time dependencies are satisfied after installation. @vindex AM_INSTALLCHECK_STD_OPTIONS_EXEMPT In a few situations, programs (or scripts)

color-tests

The automake manual for automake 1.10.2 documents the option color-tests to AM_INIT_AUTOMAKE, but if I try to use it with 1.10.2 it complains that it doesn't exist, and indeed I can find no trace of it in the code. Presumably it should either be implemented, or the documentation removed? --

Making dejagnu return status codes

I wrote to bug-dejagnu some time ago: I am having some problems with a DejaGnu test suite, but the problem itself is not what I'm writing about. At the end of a testsuite, I get the following: [snip] note that DejaGnu itself does not fail, and the make continues; in this case, it finishes

Re: Using GNU Make

On Tue, 7 Apr 2009, Mike Frysinger wrote: On Tuesday 07 April 2009 18:40:31 Reuben Thomas wrote: On Tue, 7 Apr 2009, Ralf Wildenhues wrote: indeed, part of any other widely used package, and with the following: In fact, gnulib already has a gnu-make module that adds a conditional which you

Re: Using GNU Make

On Mon, 6 Apr 2009, Ralf Wildenhues wrote: What do you mean by allow it to be required. You can require it now for your package using autotools. Right, and my original question was to ask how do I require GNU Make in an autotoolised package? I'm still don't see an official answer to that

Re: Using GNU Make

On Fri, 3 Apr 2009, Mike Frysinger wrote: On Friday 03 April 2009 20:01:15 Reuben Thomas wrote: Is there a standard way to make an autotoolised build system require GNU Make? I'm getting a bit fed up having to express everything in POSIX make when most systems now seem to have GNU Make, even

Re: Using GNU Make

On Sat, 4 Apr 2009, Ralf Wildenhues wrote: You could test '$MAKE --help' at configure time, but the problem is, few users remember to use './configure MAKE=gmake gmake', most just do './configure gmake'. You would teach them! :-) Ah, so there's no test that does this already? I would

Re: Using GNU Make

On Sat, 4 Apr 2009, Ralf Wildenhues wrote: * Reuben Thomas wrote on Sat, Apr 04, 2009 at 01:44:48PM CEST: I would imagine an AC_MAKE_GNU (or somesuch) that looks at make's help output, then tries gmake (and gnumake?) if make is not GNU Make. Oh, and I've just found check_gnu_make.m4

Re: Using GNU Make

On Sat, 4 Apr 2009, Mike Frysinger wrote: maybe use GNUmakefile.am rather than Makefile.am ? and then keep a dummy Makefile around that merely says hey sucka, GNU-make only! and/or just re- run the specified command as gmake ... Thanks. I've actually for one reason and another managed to

Re: Using GNU Make

On Sat, 4 Apr 2009, Mike Frysinger wrote: what would be cool is if automake processed some GNU makeisms in the .am - .in step. personally, i use some things like $(wildcard) and $(patsubst) because i hate having to hand maintain a huge list of files -- i inevitably add more and forget to

Using GNU Make

Is there a standard way to make an autotoolised build system require GNU Make? I'm getting a bit fed up having to express everything in POSIX make when most systems now seem to have GNU Make, even where it's not installed as the default make. -- http://rrt.sc3d.org/ | fiction, n. fact

Order-only prerequisites without assuming GNU make

Hi, I need an order-only prerequisite, but I don't want to assume GNU make. What should I do? In case it helps, the exact problem I have is this: I'm using help2man in my project. Users have complained that it's not widely installed, and can be tricky to install on older systems (because of

Re: EXTRA_PROGRAMS not automatically cleaned

On Sun, 31 Aug 2008, Ralf Wildenhues wrote: Hi Reuben, * Reuben Thomas wrote on Thu, Aug 28, 2008 at 09:07:51PM CEST: I see. Well, it's possible I'm just misusing EXTRA_PROGRAMS: I'm trying to build a program that is not to be installed, and is not a check program: it's a program I need

Re: EXTRA_PROGRAMS not automatically cleaned

On Thu, 28 Aug 2008, Ralf Wildenhues wrote: Hmm, I'm not sure but I can imagine a situation where the Makefile.am author sometimes wants a program in EXTRA_PROGRAMS to be built and removed upon 'all' and 'clean', and sometimes wants neither to happen; e.g., because building the program is very

EXTRA_PROGRAMS not automatically cleaned

I just noticed that programs listed in EXTRA_PROGRAMS in Makefile.am are not automatically added to any clean target, so make distcheck fails. I can of course add $(EXTRA_PROGRAMS) to CLEANFILES, but it seems odd as I don't have to do that for other programs, e.g. bin_PROGRAMS or

Re: DejaGnu test directory layout

On Thu, 21 Aug 2008, Ralf Wildenhues wrote: Hello Reuben, * Reuben Thomas wrote on Tue, Aug 19, 2008 at 06:44:31PM CEST: On Tue, 19 Aug 2008, Reuben Thomas wrote: From the DejaGnu manual: DejaGnu require the directory be named `testsuite'. Automake by default makes dejagnu look

Re: DejaGnu test directory layout

On Thu, 21 Aug 2008, Ralf Wildenhues wrote: * Reuben Thomas wrote on Thu, Aug 21, 2008 at 10:20:38AM CEST: On Thu, 21 Aug 2008, Ralf Wildenhues wrote: Not sure what the result of both your messages combined is. Care to formulate it as a patch against the manual? I'm not proposing a fix

Typo in manual

None of these rules do support - None of these rules supports (Two corrections: do is redundant, None is singular.) -- http://rrt.sc3d.org/ | Caution Children At Play Drive Slowly (Anon)

Re: Typo in manual

On Tue, 19 Aug 2008, Ralf Wildenhues wrote: Hi Reuben, Thanks for the report. * Reuben Thomas wrote on Tue, Aug 19, 2008 at 05:30:53PM CEST: None of these rules do support - None of these rules supports (Two corrections: do is redundant, None is singular.) Hmm, I guess. I needed to look

Typo in manual

almost staled - almost stalled

Re: Tidy-up of node Why doesn't automake support wildcards?

Patch attached for documentation as per bug-automake list discussion. Change log: 2008-02-23 Reuben Thomas [EMAIL PROTECTED] * doc/automake.texi: Improve Why doesn't Automake support wildcards node's English and sense.diff --git a/doc/automake.texi b/doc/automake.texi index

Patch to doc/automake.texi to fix capitalisation in contents

The attached patch against current git fixes some incorrectly lower-cased section names. -- http://rrt.sc3d.org/ | The shorter the betterdiff --git a/doc/automake.texi b/doc/automake.texi index c0ace40..c1df445 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -285,11 +285,11 @@

  1   2   >