0432ea 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 cond
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 fi
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
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
&g
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 pos
ained well 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
MI
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
S
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
> t
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 curr
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
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:
>
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
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
/hom
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 g
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)
noinst_
I found the "Rules-*" feature of gettext to do this; sorry for the noise!
--
https://rrt.sc3d.org
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
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
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
anothe
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: $(EM
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 other
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 a
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
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 the
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
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
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
[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 i
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
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 cha
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
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 str
a support are likely 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=UT
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 builddir.
dated 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&
--api-version
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
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 va
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!
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.
>
>
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
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 you
On 22 April 2018 at 10:28, Mathieu Lirzin wrote:
>
> > $(srcdir)/foo.1: foo.c foo$(EXEEXT)
> > -@case '$?' in \
> > *foo.c*)
> > $(AM_V_P) && set -x || echo " HELP2MAN $@"; \
> > LANGUAGE= help2man --output="$(srcdir)/foo.1" ./foo$(EXEEXT);; \
> > *) : ;; \
> > esac;
> >
> > Nice! The on
On 21 April 2018 at 16:13, Mathieu Lirzin wrote:
> Hello Reuben,
>
> Reuben Thomas writes:
>
> > In the manual, we are given the following pattern for using help2man
> > without breaking make distcheck:
> >
> > foo.1: foo.c $(top_srcdir)/configure.ac
>
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 result
I just noticed, and still present in git: requited → required
--
http://rrt.sc3d.org
On 20 May 2016 at 16:49, Mathieu Lirzin wrote:
> Reuben Thomas writes:
>
> > 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 loo
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 driver that converts expected errors into
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 error when given inval
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 test harness.
>
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
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
On 29 December 2013 22:24, Stefano Lattarini wrote:
> 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, but I find autotools a pa
On 26 December 2013 15:39, Stefano Lattarini wrote:
>
> 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 reason why AM_PROG_AR
I am using automake 1.13.3. I noticed in the manual the following sentence
in the section on building static libraries, which I do for my project with
libgnu.a:
You should call 'AC_PROG_RANLIB' from your 'configure.ac' to define
'RANLIB' (Automake will complain otherwise).
I call AM_PROG_AR, and
On 22 November 2012 13:01, Stefano Lattarini wrote:
> 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
> Debian and Ubuntu ...
>
On 21 November 2012 13:41, Stefano Lattarini wrote:
> tags 10227 + moreinfo
> thanks
>
> Hi Roumen, Reuben.
>
> I'm going through old open bugs, and I've noticed this one. Is the
> problem still present, after the recent updates to the python support?
> (They should be already merged in the maint
On 11 October 2012 22:12, Jack Kelly 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 down single core
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: $(builddi
expending → expanding
Checked in current git HEAD.
--
http://rrt.sc3d.org
On 5 July 2012 07:19, Gary V. Vaughan 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
>
> tes
On 4 July 2012 23:35, Stefano Lattarini 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 .dl
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, whic
ve 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
Date: Mon, 5 Dec 2011 23:40:48 +0100
Subject: [PATCH] Remove Python 1.5 support.
---
m4/python.m4 | 14 -
The code currently used to get the python package directory is wrong
for Python 3:
>>> from distutils import sysconfig; print
>>> (sysconfig.get_python_lib(0,0,'/usr/local'))/usr/local/lib/python3/dist-packages
is wrong (should be /usr/local/lib/python3.2/dist-packages). Now, in
some sense this mu
Sep 17 00:00:00
2001From: Reuben Thomas Date: Mon, 5 Dec 2011 23:40:48
+0100Subject: [PATCH] Remove Python 1.5 support.
--- m4/python.m4 | 14 -- 1 files changed, 4
insertions(+), 10 deletions(-)
diff --git a/m4/python.m4 b/m4/python.m4index a7c1dd7..642b498
100644--- a/m4/python.m4+++
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 modell
On 4 March 2011 17:14, Ralf Wildenhues wrote:
> * Reuben Thomas wrote on Thu, Mar 03, 2011 at 04:42:33PM CET:
>>
>> Thoughts?
>
> We could just provide thin-layer support for both latexmk and/or rubber.
This sounds good, and John Collins has pointed out that latexmk do
On 2 March 2011 22:13, Reuben Thomas wrote:
> On 2 March 2011 22:12, Ralf Wildenhues 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 more
On 2 March 2011 22:12, Ralf Wildenhues 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.
--
http://rrt.sc3d.org
On 28 February 2011 20:43, Ralf Wildenhues wrote:
> Hi Reuben,
>
>
> I'm not sure if I said it before; but I wouldn't be surprised if there
> is interest to let latexmk (continue to) exist independently from
> Automake.
That's what I was assuming.
> It's not even clear how big the benefit of a
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?
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
functionalit
On 27 February 2011 14:42, Ralf Wildenhues 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
> that to portable make
On 27 February 2011 06:53, Ralf Wildenhues 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
document.
I suppose t
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 A
Section EXEEXT:
"Unfortunately, due to the change in Autoconf 2.50, this means you
must always add this extension. However, this is a problem for
maintainers who know their package will never run on a platform that has
executable extensions."
It is unclear to me how the fact that you must always
tring] Small "make install" problem
To: bug-libunistr...@gnu.org
Cc: Reuben Thomas
Hi,
Reuben Thomas wrote in
<http://lists.gnu.org/archive/html/bug-libunistring/2010-04/msg2.html>:
> When I "sudo make install 0.9.2.1", where my user's umask is 0027, all
> of t
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) hav
2009/7/25 Ralf Wildenhues :
>
> Can you suggest a patch, so we can see if this really reads better than
> the current version?
Attached.
--
http://rrt.sc3d.org
Too late: it’s like sticking plasters on a coffin
diff --git a/doc/automake.texi b/doc/automake.texi
index b3f4a76..5c23fea 100644
--- a
The Gnits node of automake manual currently (1.10.2) duplicates the
documentation for various options to AM_INIT_AUTOMAKE. It would be
better to say simply that the option "gnits" implies "std-options",
"readme-alpha" and "check-news" (this latter is not currently stated
explicitly), and give an xr
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?
--
http:
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 fini
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
On Tue, 7 Apr 2009, Ralf Wildenhues wrote:
* Reuben Thomas wrote on Mon, Apr 06, 2009 at 10:38:55PM CEST:
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 qu
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 th
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 updat
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 av
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_
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 i
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,
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 without
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
On Wed, 25 Feb 2009, Ralf Wildenhues wrote:
Hello Reuben,
* Reuben Thomas wrote on Mon, Feb 23, 2009 at 03:19:10PM CET:
what's the status of this macro?
It is still not documented. It is not deprecated either, but as the
'missing' script is not easily extensible by the user,
what's the status of this macro? With a quick google I can find a discussion
about documenting it, and apparently a commit of a patch to document it, in
November 2007, but I can't find any evidence of its ever having been
committed in the git repo.
I ask because I found a use of AM_MISSING_PRO
At present, from looking at dejagnu.am, there seems to be no way to get
configure to write extra values into dejagnu's site.exp. For example, I want
to write the path of a program found using AC_PATH_PROG. Is there a usual
way to do this?
--
http://rrt.sc3d.org/ | competent, a. under-promoted
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
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 e
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 check_PROGRAMS.
Some of my DejaGnu testsuite for a particular project (GNU Zile) need to be
run by the installcheck target. I can't see a documented way of making
automake call dejagnu as part of installcheck rather than check; did I miss
something, or is there an easy workaround?
--
http://rrt.sc3d.org/ | pr
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
1 - 100 of 122 matches
Mail list logo
