Karl Berry writes:
> For GNU packages, dvi and pdf will normally be tested anyway as part of
> a release, due to the need to upload the new manuals to www.gnu.org.
> Perhaps we should remove dvi from there ... -k
Yes, as a start, could we drop linking to DVI manuals from gnulib's
gendocs_templat
-dvidir.
All of these would have to be removed.
> So is this about changing automake/autoconf then?
I wouldn't suggest to change Automake or Autoconf before the Standards
have been changed.
Bruno
d). Nowadays, even the math arXiv does not offer DVI as a
> download format any more [1]. But this needs to be done through the
> proper channels: first the GNU standards, then GNU Autoconf and Automake.
Right. I would say that the days of the DVI and PS formats are probably
long gone, a
I would like to request a feature for GNU Automake if it is possible.
When building programs and libraries with GNU Autotools (libtool,
aclocal, automake, and autoconf) it is sometimes desirable to compile
the same source with a custom compiler (other than CC, CXX, etc.). A
sample use case
The first paragraph in
https://www.gnu.org/software/automake/manual/html_node/Linking.html
can be interpreted in a misleading way:
"If you need to link against libraries that are not found by configure,
you can use LDADD to do so. This variable is used to specify additional
objec
Short mail sent by mistake. Sorry.
Hi,
The first paragraph in
Fix a whitespace typo in a comment.
--
https://rrt.sc3d.org
From 4638ba5734a0969e644a84903cf2772047cd52b2 Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Fri, 18 Apr 2025 07:34:27 +0100
Subject: [PATCH] doc: fix typo in comment
* lib/am/check.am: remove a spurious space after a hyphen
---
l
>
> Ideally, the date would be chosen and stored in a static file as part of
> your upstream release process, i.e. when you are about to release m4-1.4.20,
> and we should not change such file unless we really meant a different time.
And that ideal is _supposed_ to be met: automake gen
e same timestamp as the last git commit
(regardless of whatever other mtime git itself assigned the file), all
before build-aux/mdate-sh is run, so that you can once again have
UPDATED in version.texi pinned to a reliable epoch despite git itself
not having the same timestamp-preserving behavior as
[dropping gnulib, but adding automake, for the reproducibility issue]
On Mon, Apr 14, 2025 at 06:04:53PM +0200, Santiago Vila wrote:
> El 14/4/25 a las 16:36, Eric Blake escribió:
> > Also, I see two
> > uses of @value{UPDATED} in m4.texi, but your patch only removed one;
> >
Karl Berry writes:
> Given Bruno's experience, ok, let's try. I won't be surprised if
> problems come out of the woodwork, but maybe it will be fine.
>
> I think the change below is all that's needed to implement this?
> I pushed it. Let me know if something more comes to mind.
Thank you!
>
wn plan, should I need to make another release of Zile (the last
release was nearly 4 years ago, and there's little chance of a significant
change requiring an update), is to just run "make dist" if it's a minor
fix, or to switch back to a recursive build system.
(Incidentally, I
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
Kirill Makurin wrote:
> I applied patches and they work for Msys2.
>
> I also tested it with (what I assume is) "Msys-based MinGW"
> (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports
> `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
> ...
> I explicitly
Kirill Makurin wrote:
> I was going to just say that this patch is good and go ahead with it, but I
> decided to check it and turns out it fixes this issue only partially, but the
> patch itself is good.
>
> Msys2 has multiple environments (see
> https://www.msys2.org/docs/environments/) and th
Karl Berry wrote:
> Kirill (cc'd) proposed setting the MSYS2_ARG_CONV_EXCL envvar in the
> compile script which comes from Automake, to avoid a double-conversion.
> See his report in the first msg here, and the final suggestion in the last:
> https://debbugs.gnu.org/cgi/bugrep
Hi automake folks,
What do you think about changing Automake's default tar format from v7
to ustar?
Are you aware of any system 'tar' that does doesn't cope with ustar?
What do you think about defaulting to the --format=posix PAX format? It
may be just as safe as ustar, a
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
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 I don't think it would work in this case.
>
On 11/21/24 12:56, Nick Bowler wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On 2024-11-20 21:56, Li, Changqing via Bug reports for Automake wrote:
The failure is
On 11/21/24 12:56, Nick Bowler wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On 2024-11-20 21:56, Li, Changqing via Bug reports for Automake wrote:
The failure is
Hi Karl,
thanks for the detailed answers.
We've run few more tests, and we've found a couple more issues.
1. As you pointed out, TAR_OPTIONS is working fine from the command
line, but it doesn't work when written inside Makefile.am, neither on
Mac, nor on Linux.
$ TAR_OPTIONS="--version"
$ ex
Good morning,
GNU Astronomy Utilities (Gnuastro) uses GNU Autotools. A Gnuastro
developer encountered the "Numeric user ID too large" error when
generating a tarball with the 'make dist' command on his macOS (Monterey
12.3) laptop. His user id is an integer with 9 digits, which is too big
for
On Tue, Sep 10, 2024 at 10:59 PM Eric Gallager wrote:
>
> On Tue, Sep 10, 2024 at 6:46 PM Karl Berry wrote:
> >
> > Hi Eric - I've just committed a change that I hope fixes the version
> > number problem. (See https://bugs.gnu.org/72157)
> >
> > However, looking at your list of failures, I see t
On Tue, Sep 10, 2024 at 6:46 PM Karl Berry wrote:
>
> Hi Eric - I've just committed a change that I hope fixes the version
> number problem. (See https://bugs.gnu.org/72157)
>
> However, looking at your list of failures, I see that some of them are
> still about *.dSYM, now relating to distclean.
On Wed, Aug 28, 2024 at 6:43 PM Karl Berry wrote:
>
> Hi Eric,
>
> Subject: bug#72852: Testsuite summary for GNU Automake 1.17 on
> x86_64-apple-darwin20.6.0
>
> Thanks for the report. It looks like Apple's compiler, or linker, or
> something, is leaving n
Karl Berry , 2024-08-25 19:17:
> - $output_rules .= "check-am: all-am\n";
> + $output_rules .= "check-am: all-am";
> if (@check)
> {
> - pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t ",
@check);
> + $output_
Karl Berry , 2024-08-25 10:45:
Thanks much, Bogdan.
-recheck: all %CHECK_DEPS%
+recheck: all-am %CHECK_DEPS%
Do you have a grip on all-am? Looking at handle_all in bin/automake, I
admit I remain baffled as to what all those pieces of all-am are, and
why it's done as it is.
Hi.
I've just noticed that bug #68860 (patched) may be a duplicate of
#26471. Different descriptions and error messages, but looks like the
same cause.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Sof
Hello.
Thank you for reporting the issue.
I believe I have fixed the defect. The attached patch assumes that
"no-dist-built-sources" is the right option name, following the
documentation and the Options.pm file.
Automake itself has been changed to process the option correctly,
dist
Hello.
Thank you for reporting the issue.
The attached patch should fix the problem. It may be a bit of an
overkill, perhaps just one of the fixes would suffice, but it seems to
work at least.
I've re-made your useful script into an Automake test. Since
non-deterministic defects may be ha
he @code{_LDFLAGS} variable for the program.
@cindex Vala Support
@cindex Support for Vala
-Automake provides initial support for Vala
-(@uref{https://www.vala-project.org/}).
-This requires valac version 0.7.0 or later, and currently requires
-the user to use GNU @command{make}.
+Automake sup
compiler optional. But I think this is a great feature of
Automake's Vala support! (Certainly, I believe it is unique.)
So if Automake had in future a mode where it shipped only Vala sources,
then in that mode it would make sense to conditionally-include Vala
sources, and that would work.
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
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
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* bin/automake.in: make the _vala.stamp file depend on the relevant
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. Indeed, I
have brok
generate C preprocessor directives, I have to do
conditional inclusion at build time some other way. So, I am doing it by
using automake conditionals.)
With current automake, something like the following Makefile line is
generated:
$(builddir)/libenchant_la_vala.stamp: api-windows.vala api-posix.vala
.
>
> Looking at automake.in, it's not obvious to me where a list is failed to
> be sorted. Those -local targets aren't generated by automake itself, so
> far as I can see. --thanks, karl.
>
GCC developers have recently found a source of non-determinism in
automake; this is bad for reproducible builds:
-- Forwarded message -
From: Jakub Jelinek
Date: Mon, Apr 15, 2024 at 8:43 AM
Subject: [PATCH] gotools: Workaround non-reproduceability of automake
To: Ian Lance
when STRIP consists of more than one word.
-# This test needs GNU binutils strip. See sister test 'strip3.sh'.
+# See sister test 'strip3.sh'.
required='cc strip'
. test-init.sh
@@ -39,7 +39,7 @@ $ACLOCAL
$AUTOCONF
$AUTOMAKE -a
-./configure --prefix="$(pwd)/inst" STRIP='strip --verbose'
+./configure --prefix="$(pwd)/inst" STRIP='strip -x'
$MAKE
$MAKE install-strip
--
2.35.1
s not added to the
command line, making the test fail during linking.
Yes, 'c++' works as an Objective-C++ compiler:
How interesting. Especially that it compiles, but doesn't link.
[...]
$ c++ -c hello.mm
$ c++ hello.mm
[3 link errors, due to undefined symbols.]
What Autoc
Bruno Haible , 2024-02-19 01:33:
Hello Bogdan,
Thank you for dealing with the Automake support.
Thank you for testing :)
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
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
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?
3) t/yacc
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
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?
3) t/yacc
Hi.
I have access to just Linux and SunOS and cannot reproduce the error
(the tests pass), but Karl's solution seems reasonable and shouldn't hurt.
Attaching a simple patch which (hopefully) fixes the issue. At
least, it doesn't hurt Linux or SunOS, so it shouldn't make things
worse. Feel free
Hello.
The attached patch fixes the tests for Python 3.12 (and, hopefully
later ones), while still keeping them working for earlier versions.
A simple fix. Could perhaps be written better (like in a single
Python script), but this is enough.
--
Regards - Bogdan ('bogdro') D. (G
Mike Frysinger , 2024-01-17 06:04:
On 14 Jan 2024 18:55, Bogdan wrote:
Mike Frysinger , 2024-01-14 02:06:
On 13 Jan 2024 22:29, Bogdan wrote:
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass a
Mike Frysinger , 2024-01-14 02:06:
On 13 Jan 2024 22:29, Bogdan wrote:
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added d
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added documentation and a test case including the '-no-suppress'
option. All tests
_SOURCES.
https://www.gnu.org/software/automake/manual/automake.html#Sources
that var is meant for generating headers before Automake's depgen logic
can kick in. that sounds minor, but in practice it means that every
built source is generated before anything else is compiled. which can
insert a
Hello.
Referring to the discussion related to the upcoming release, I
confirm defect #64837 on Debian GNU/Linux 12 (bookworm) and I confirm
that the last patch in #54412 (the one attached in the defect in
Message#14 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412#14,
not the one inlined) f
e done.
I don't have Python 3.10 or Ubuntu/Debian, but maybe I'll play with
this anyway, I'll see. It may be a bit of a guessing game with more
than 1 attempt. Fortunately, it's "just" the test that's failing
because the paths are different and it&#
istribution that is made. That way the user
@@ -6359,11 +6360,11 @@ What Automake cannot guess, though, is where this header will be used:
it is up to you to ensure the header gets built before it is first
used. Typically this is necessary in order for dependency tracking to
work when the he
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
In Docker(in the vmware ubunt also has the problem):
Environment:
Ubuntu 20.04 5.15.0-78-generic.
Automake1.4 from ftp://gcc.gnu.org/pub/java/automake-gcj-1.4.tar.gz.
root@576a62413a36:~/automakeOut# automake --version
syntax error at /usr/local/bin/automake line 932, near "
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_
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 libra
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
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 in
, Jan 24, 2023 at 7:06 AM Bert Wesarg wrote:
>
> On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg wrote:
> >
> > On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake
> > wrote:
> > > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote:
&g
On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg wrote:
>
> On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake
> wrote:
> > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote:
> > No, I don't have one. It just crossed my eyes while working o
over the bug ? we'd want to write a test for it so we
> can be sure it doesn't fail again.
No, I don't have one. It just crossed my eyes while working on more
silent rules in Automake. I made Ben recently aware of these changes,
which are availalbe here:
https://github.com/
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 man
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_
Hi!
I download https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.gz
and compiled it. I have several tests failed in `make check ` command
Most of them are marked with # TODO long-standing limitation
but there are several other failed tests
I configured installation with non-statndard path
On 2/20/22 14:00, Mike Frysinger wrote:
On Fri, 26 Jul 2013 11:32:18 -0400, Diab Jerius wrote:
The fort5 test fails on Mac OS X 10.6.8.
the failing part of the log:
/bin/sh ./libtool --tag=FC --mode=link gfortran -g -O2 -o libhello.la
-rpath /usr/local/lib foo.lo bar.lo libgoodbye.la
li
ed to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
The documentation mentions in several places that the variables set by
Automake are only really designed to be used in the Makefiles that it
generates. Using AC_SUBST to directly subst
ed to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
The documentation mentions in several places that the variables set by
Automake are only really designed to be used in the Makefiles that it
generates. Using AC_SUBST to directly subst
Hi,
in commit
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670
line 160 of python.m4
you changed the sed command so that am_cv_python_pythondir does not
contain the content of $PYTHON_PREFIX anymore but the variable name
$PYTHON_PR
I download https://github.com/crosstool-ng/crosstool-ng.git and try to build
it under cygwin and get error automake-1.16: error: unrequested trace '$n'
(1j0/cygdrive/c/Users/feelus/_repos/_foreign)--0---(feelus@feelus-PC@23:53)
[503] $ git clone --depth 1 --config core.auto
lly a bug in the latest
ax_code_coverage.m4 that quotes AC_MSG_ERROR() which causes older
autoconf/automake versions to barf.
https://github.com/c-ares/c-ares/commit/3883d99b05a845e4b40fc25c43ca83db70f4f20f#diff-fe38622a6c742be1bb93e6e65a0728f659114b3dc8d88172cb8844fa963418f9
I'm not sur
On 8/17/21 1:06 PM, Nick Bowler wrote:
On 2021-08-17, Brad House via Bug reports for Automake
wrote:
I'm one of the maintainers of the c-ares project at
https://github.com/c-ares/c-ares and have had a couple of users report
this issue.
I took a quick glance and I found this:
I'm one of the maintainers of the c-ares project at
https://github.com/c-ares/c-ares and have had a couple of users report
this issue. At first glance it appears to be an issue introduced
between automake 1.16.1 and 1.16.3.
I actually did some testing on MacOS 11.4 with automake 1.16.
On Sun, May 9, 2021 at 9:28 PM Karl Berry wrote:
>
> Ei Eric,
>
> Automake::ChannelDefs::prog_error("too many loops") called at
> /opt/local/bin/aclocal line 1187
>
> I've never seen that error before. The comment in aclocal where the
> check i
severity 48113 wishlist
retitle 48113 Self-test timeout functionality
thanks
Karl Berry writes:
> What do bug-automake people think?
>
> For myself, I have no objection to sprinkling timeout commands through
> the Automake test infrastructure wherever appropriate. It's no
of a Scheme compiler used as a build tool; thanks to
> Turing-completeness of Scheme macros, such a build may not terminate).
This makes me believe even stronger that the functionality ought to be
provided by automake natively -- it seems the desired functionality is
not only timeouts for self-tes
lf-tests is a good one. However I reach the same conclusion as Bruno,
that having a module like valgrind-tests is probably not the best way to
solve it. To me, having a timeout seems like an essential feature of a
self-test framework. I know automake isn't primarily a self-test
framework,
.m4' from
'/opt/local/share/aclocal/ax_cxx_compile_stdcxx_11.m4'
aclocal: installing 'm4/ax_require_defined.m4' from
'/opt/local/share/aclocal/ax_require_defined.m4'
aclocal: error: too many loops
aclocal: Please contact .
at /opt/local/share/automake-1.16/Automake/Channels.pm line 655
is a patch courtesy of Dirk Müller.
Josef
--- automake-1.16.3/bin/automake.in
+++ automake-1.16.3/bin/automake.in
@@ -2388,7 +2388,7 @@
$var->requires_variables ("\@${lt}LIBOBJS\@ used", $lt . 'LIBOBJS')
if ! keys %libsources;
- foreach my $iter (keys %libsources)
The source of the problem is that /dev/null was a regular file on my system.
I checked against this before filing the bug, but not in proper ways.
I am sorry for the inconvenience.
Subject: obscure bug "extern void free (void *__ptr) __attribute__
((__nothrow__ , __leaf__));"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALU
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, CXX etc.). I've
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
2, Karl Berry wrote:
> Reuben - any chance you can look into this vala failure?
>
> It seems that, (only) in the make distcheck done inside the test, the .c
> files are not remade from the .vala?
>
> Thanks,
> Karl
>
>
> Date: Fri, 20 Nov 2020 22:25:55 +0100
> From
If your current directory path contains a space then Automake creates an
invalid site.exp file. The problem is in the following code placed into
Makefile.in:
@echo 'set srcdir "$(srcdir)"' >>site.tmp
@echo "set objdir `pwd`" >>site.tmp
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
I'm trying to port a project to docker and I'm also testing it on my
Raspberry Pi 3B+
when I *./configure* and *make* the project, it fails with this message
gcc: error: unrecognized -mcpu target: armv7l
gcc: note: valid arguments are: arm8 arm810 strongarm [...] cortex-a53 [...]
gcc: error: miss
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
1 - 100 of 115 matches
Mail list logo
