the issue, and to
J. Random Hacker for providing suggestions and testing the patch.
--8<---cut here---end--->8---
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
, I will close this bug.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
re.
Both patches were applied in commit 6624f88b2ea685e5c44c7373d01df488d1dabd19.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
his minor deefficiency,
> Best Regards,
> Sjoerd van Leent
I am not familiar with the details of how Flex is working but supporting
the ‘--prefix’ option seems desirable. Currently Automake has very
little manpower, so I encourage you to work on it yourself if you have
some time to devote to it.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
CES = Main.cpp
>> myprog_CXXFLAGS = -DANY
>> AM_CPPFLAGS = -I@MYPROG_PATH@
>> VPATH=@MYPROG_PATH@
>
> Don't set VPATH like this. It supersedes the definition supplied by
> Automake and is almost certainly the cause of your problems.
I agree with your analysis, so I am closing this bug.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
om the Automake manual:
lib_LTLIBRARIES = libgettext.la
libgettext_la_SOURCES = gettext.c ...
bin_PROGRAMS = hello
hello_SOURCES = hello.c ...
hello_LDADD = libgettext.la
Does it help?
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Mark Thomas writes:
> Yes, using a space in place of "\n" works on my system.
Pushed as commit a348d830659fffd2cfc42994524783b07e69b4b5.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
h for those
> discussions any more :(. Hardly the most crucial suggestion in the
> world, fine for it to be relegated to the dustheap of history :).
No need to be old to be relunctant about starting this kind of
discussions which are often painful. :-)
Feel free to reopen the bug if you change
ersonnaly not against your suggestion as long as it matches the
GCS recommandation. So I would suggest discussing it on
or to see if others
agree that GCS is outdated in that regard before modifying the Automake
manual. WDYT?
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
tp://lists.gnu.org/archive/html/automake-patches/2018-05/msg1.html
I am going to review those.
Thanks for reminding us about that.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
ed in Automake's manual. Have you any suggestion
regarding the location and wording?
Thanks.
[1] https://www.gnu.org/software/automake/faq/gnulib.html#VCS-Issues
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
NERCLEANFILES, e.g.:
>
> MAINTAINERCLEANFILES = aclocal.m4 config.h.in configure \
>Makefile Makefile.in */Makefile */Makefile.in
>
> Some maintainers might prefer to also remove build-aux or more; personally
> that's one step too much for me. All the more reason not t
bst_variables_worker ($1)/ge;
>
> Since newer versions, Perl enforces the escape of this brackets.
This is fixed since Automake 1.16
Thanks for the bug report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Hello Peter,
Peter Johansson writes:
> On 4/22/2018 1:13 AM, Mathieu Lirzin wrote:
>> Hello Reuben,
>>
>> Reuben Thomas writes:
>>
>>> In the manual, we are given the following pattern for using help2man
>>> without breaking make distcheck:
&g
Reuben Thomas writes:
> On 21 April 2018 at 16:13, Mathieu Lirzin wrote:
>
> 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)/conf
ninstall-am: uninstall-%DIR%PYTHON
uninstall-%DIR%PYTHON:
Can you confirm it works on your system?
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
--cut here---end--->8---
This solution handles silent rules and possible localization of the
‘./foo --help’ output. However its limitation is that if you have
another rule with ‘$(srcdir)/foo.1’ as a prerequisite then it will be
triggered at every build.
WDYT?
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Mathieu Lirzin writes:
> This is likely related to commit
> 826408a7f6ca4c39ff7b7ac9952c05f48110748f [1] which make those tests work
> with Flex 2.6.4 and g++ 7.3.
>
> If you know a good way to achieve a better compatibility than the
> solution chosen by that commit, I would be
bility than the
solution chosen by that commit, I would be interested.
Thanks for the report.
[1]
https://git.savannah.gnu.org/cgit/automake.git/commit/?id=826408a7f6ca4c39ff7b7ac9952c05f48110748f
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Torsten Seemann writes:
> That patch looks good - removing List::Util altogether is probably the right
> thing. And tests too.
Pushed as commit 74902aa24d4c313ab51fa684142d9240f636971a.
Thanks for the review.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Mathieu Lirzin writes:
> Here is an alternative patch to fixes this bug, that I intend to push
> tomorrow.
>
>>From 88df0576249df21e719ff3ac95d3d27b77e3370f Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin
> Date: Sat, 3 Mar 2018 12:01:13 +0100
> Subject: [PATCH] pytho
t::Util.
This requirement could probably be relaxed since Perl 5.6 is 18 years
old, however this can't be done in the micro (bugfix) release I intend
to make after fixing this bug. So let's reimplement it ourselves for
now.
>From 666b787749b5986f7a30453741ca206b6b6ff164 Mon Sep 1
Hello,
Mathieu Lirzin writes:
> Mathieu Lirzin writes:
>
>>>>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
>> From: Mathieu Lirzin
>> Date: Thu, 1 Feb 2018 13:51:03 +0100
>> Subject: [PATCH] python: Generate python interpreter list
Eric Blake writes:
> On 02/26/2018 02:30 PM, Mathieu Lirzin wrote:
>
>>>> /usr/bin/m4:configure.ac:506: bad expression in eval (bad input): ($+1) !=
>>>> (2)
>>>> /usr/bin/m4:configure.ac:506: bad expression in eval (bad input):
>>>> (0r
thon
> version or newer on my system, configure fails like expected.
Given the other portability problems the faulty commit has, I think
simply reverting it as suggested by Eric Blake seems better.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
9: /usr/bin/m4 failed with exit status: 1
>> aclocal-1.16: error: echo failed with exit status: 1
As pointed by Andriy, commit 1d60fb72168e62d33fe433380af621de64e22f23 is
faulty here.
There is an issue with AM_PATH_PYTHON quoting. When a fix is proposed,
I will make a micro (bug fix) release.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
released in Automake 1.16.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
following PEP394 [1] like Arch Linux, the test suite
fails (See attached log).
test-suite.log
Description: Binary data
[1] https://www.python.org/dev/peps/pep-0394/
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Hello,
Mathieu Lirzin writes:
> Mathieu Lirzin writes:
>
>>>>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
>> From: Paolo Bonzini
>> Date: Mon, 31 Oct 2016 13:30:50 +0100
>> Subject: [PATCH] automake: Do not require ltmain.sh for o
Mathieu Lirzin writes:
> "t/instmany-python.sh" test fails for the ‘uninstall’ target.
This is fixed by commit 006c4dfede96091f5bed622c17946cbec067347f
>From 006c4dfede96091f5bed622c17946cbec067347f Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin
Date: Sun, 4 Feb 2018 00:09:
Hello,
Mathieu Lirzin writes:
>>From 83d5d37bc8f0adb0e20a6fe7ab68029d2479dd32 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin
> Date: Thu, 18 Jan 2018 11:19:13 +0100
> Subject: [PATCH] tests: Don't check 'Getopt::Long' corner cases
>
> Depending on the
Mathieu Lirzin writes:
>>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin
> Date: Thu, 1 Feb 2018 13:51:03 +0100
> Subject: [PATCH] python: Generate python interpreter list
>
> _AM_PYTHON_INTERPRETER_LIST is used by AM_PYTH
Hello,
aotto writes:
> the following line create a BUG in autoconf
>> # if 'CFLAGS' is NOT set, than macro 'AC_PROG_CC' set 'CFLAGS=-g -O2'
> in seems that a M4-MACRO in COMMENT is a problem.
Since the issue is related to Autoconf please report it to
Hello,
Mathieu Lirzin writes:
>>> On 09/15/17 11:17, Mathieu Lirzin wrote:
>>>> Instead of preemptively adding possible future version of Python that
>>>> hopefully would be released, I would prefer a solution that removes the
>>>> need to hard-cod
"t/instmany-python.sh" test fails for the ‘uninstall’ target. Here is
the failing part which runs a 6558 characters command:
--8<---cut here---start->8---
( cd
'/home/mthl/src/automake/t/instmany-python.dir/inst/lib/python3.5/site-packages'
&& rm -f __pycache
> /NODEFAULTLIB[:library]
> /NOLOGO
> /OUT:filename
> /REMOVE:membername
> /SUBSYSTEM:{BOOT_APPLICATION|CONSOLE|EFI_APPLICATION|
> EFI_BOOT_SERVICE_DRIVER|EFI_ROM|EFI_RUNTIME_DRIVER|
> NATIVE|POSIX|WINDOWS|WINDOWSCE}[,#[.##]]
> /VERBOSE
> /WX[:NO]
> =======
&
sav...@ukr.net writes:
> --- Оригінальне повідомлення ---
> Від кого: "Mathieu Lirzin"
> Дата: 18 січня 2018, 00:45:20
>
> > I have took a quick look a GMP “configure.ac” and it seems that they
>> have an option ’--enable-cxx’ which triggers the use of the
t.
2. Remove $(AM_MAKEINFOFLAGS) from the dvi, ps, and pdf targets
I am not sure what should be done. Enlightened suggestions are welcome.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
those tests want to ensure that the code is invalid C.
What would seem a more robust solution would be to include
instead and make the code invalid C by another mean.
Sorry for long delay. Thanks for the report.
[1] https://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Mathieu Lirzin writes:
> ‘hammer’ and ‘spanner’ are not found when running ‘make distcheck’
> because they are not ditributed in the tarball. Those scripts are
> declared in the DEJATOOL special variable. So I am wondering if the
> contents of this variable should be automatically
Hi Seth,
Mathieu Lirzin writes:
> Seth Fowler writes:
>
>> I recently ran into what appears to be a bug in automake and I thought it
>> would be a good idea to let you know.
>>
>> We had noticed that running “make recheck -j8” if some source files
>>
Hello,
Mathieu Lirzin writes:
> Mathieu Lirzin writes:
>
>> I was able to reproduce this bug on my machine (Fedora 25) with the
>> minor development branch (v1.15.0a). The FAILING tests are related to
>> the presence of DejaGNU on the system. Unfortunately I have neve
Mathieu Lirzin writes:
> Carnë Draug writes:
>
>> There are 3 variables used by automake when calling dejagnu's
>> runtest:
>>
>> $RUNTESTDEFAULTFLAGS - default from automake
>> $AM_RUNTESTFLAGS - set by package developer
>> $RUNT
Hello,
Mathieu Lirzin writes:
> Dennis Clarke writes:
>
>> The five failed tests are :
>>
>> FAIL: t/aclocal.sh
>> FAIL: t/automake-cmdline.tap 4 - list of options terminated by '--' (stderr)
>> FAIL: t/automake-cmdline.tap 17 - unambiguous incom
Hello,
Mathieu Lirzin writes:
> Sostom M N writes:
>
>> I am trying to run autoreconf , and this is what i get:
>> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of
>> AM_PATH_LOG4C
>> /usr/share/aclocal/log4c.m4:7: run info Automake 'Exten
exit $?
> ;;
> - cl | *[/\\]cl | cl.exe | *[/\\]cl.exe )
> + cl | *[/\\]cl | cl.exe | *[/\\]cl.exe | \
> + icl | *[/\\]icl | icl.exe | *[/\\]icl.exe )
> func_cl_wrapper "$@" # Doesn't return...
> ;;
> esac
> ===
>
> but it's not convenient to update build system of OSS Projects before each
> build.
> Can this fix be merged to Automake sources directly?
Indeed, The great news is that support for ‘icl’ has already been added
in Automake 1.15.1 [1]. :-)
Could you confirm it works correctly with Automake 1.15.1?
Note: When building libiconv you have to use ‘autoreconf -i’ or
something similar in order to have the local ‘compile’ script updated.
Thanks for the report.
[1] https://lists.gnu.org/archive/html/info-gnu/2017-06/msg7.html
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
; '_AM_PROG_CXX_C_O' or other subroutine for C++ compilers check,
> similar to '_AM_PROG_CC_C_O' for C compilers, which would provide this
> fix.
It will indeed be nice to fix the issue you face, however I guess this
should not be done not on Automake side, because AM_PROG_CC_C_O is
obsolescent [1].
I have took a quick look a GMP “configure.ac” and it seems that they
have an option ’--enable-cxx’ which triggers the use of the AC_PROG_CXX
macro which I guess should set things properly (I am not an Autoconf
expert), If not this is either an issue with GMP configuration or with
With AC_PROG_CXX implementation.
Could you investigate with the ’--enable-cxx’ option?
Thanks for the report.
[1]
https://www.gnu.org/software/automake/manual/html_node/Public-Macros.html#index-AM_005fPROG_005fCC_005fC_005fO
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Hello Paolo,
Mathieu Lirzin writes:
>>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini
> Date: Mon, 31 Oct 2016 13:30:50 +0100
> Subject: [PATCH] automake: Do not require ltmain.sh for out-of-tree libtool
>
> If Automake does not
I am opening a bug to keep track of this.
Mathieu Lirzin writes:
> Paolo Bonzini writes:
>
>> On 31/10/2016 13:30, Paolo Bonzini wrote:
>>> If Automake does not see LT_SUPPORTED_TAG, it assumes an old libtool
>>> that does not know about AC_REQUIRE_AUX_FILE. Ho
7;\d+\.\d+([a-z]|\.\d+)?(-[A-Za-z0-9]+)?';
--8<---cut here-------end--->8---
Ideally with some unit tests. :-)
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Eric Blake writes:
> On 01/04/2018 07:49 PM, Mathieu Lirzin wrote:
>
>> for example from Automake 1.15.1 build directory the following command
>> is supposed to work:
>>
>> --8<---cut here---start->8---
>> $ t/
e how to properly handle this for now. More investigation would
be needed.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Hello Chris,
Mathieu Lirzin writes:
> Chris Daley writes:
>
>> The Vala compiler also supports a language called Genie, which is
>> very similar to Python but compiles down to C in the same way that
>> Vala does. Genie files can be mixed with Vala files on the comm
sn't work on your system. My impression
is that those failing tests are checking the edge cases of Getopt::Long
which is system dependent and not the functional behavior of Automake.
As a consequence it seems reasonable to narrow the tests to more
conservative Getopt::Long behaviors.
WDYT?
Sorry for the delay.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
by GNU Automake config.status 1.15a, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES=
CONFIG_HEADERS =
CONFIG_LINKS=
CONFIG_COMMANDS =
$ ./config.status --file=-
on localhost.localdomain
## -- ##
## Running config.status. ##
## -- ##
This file was extended by GNU Automake config.status 1.15a, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES=
CONFIG_HEADERS =
CONFIG_LINKS=
CONFIG_COMMANDS =
$ ./config.status --file=-
on localhost.localdomain
## -- ##
## Running config.status. ##
## -- ##
This file was extended by GNU Automake config.status 1.15a, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES=
CONFIG_HEADERS =
CONFIG_LINKS=
CONFIG_COMMANDS =
$ ./config.status --file=-
on localhost.localdomain
## -- ##
## Running config.status. ##
## -- ##
This file was extended by GNU Automake config.status 1.15a, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES=
CONFIG_HEADERS =
CONFIG_LINKS=
CONFIG_COMMANDS =
$ ./config.status --file=-
on localhost.localdomain
## -- ##
## Running config.status. ##
## -- ##
This file was extended by GNU Automake config.status 1.15a, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES=
CONFIG_HEADERS =
CONFIG_LINKS=
CONFIG_COMMANDS =
$ ./config.status --file=-
on localhost.localdomain
## -- ##
## Running config.status. ##
## -- ##
This file was extended by GNU Automake config.status 1.15a, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES=
CONFIG_HEADERS =
CONFIG_LINKS=
CONFIG_COMMANDS =
$ ./config.status --file=-
on localhost.localdomain
## -- ##
## Running config.status. ##
## -- ##
This file was extended by GNU Automake config.status 1.15a, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES=
CONFIG_HEADERS =
CONFIG_LINKS=
CONFIG_COMMANDS =
$ ./config.status --file=-
on localhost.localdomain
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
ce this bug has already
been fixed in Automake 1.15.1. I am closing this bug.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
;automake\"
> -DPACKAGE_VERSION=\"1.15\" -DPACKAGE_STRING=\"GNU\ Automake\ 1.15\"
> -DPACKAGE_BUGREPORT=\"bug-automake@gnu.org\"
> -DPACKAGE_URL=\"http://www.gnu.org/software/automake/\";'
The fact that PACKAGE_VERSION and PACKAGE_STRING refers to 1.15 is not
normal. It should be 1.15.1.
Could this be possible that you are building Automake 1.15 and not
1.15.1?
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21001.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
/perl5/site_perl) at bin/automake line 48.
> BEGIN failed--compilation aborted at bin/automake line 48.
Oops my bad, I should have asked for the output of 't/wrap/automake-1.15
--help' instead.
Can you provide it?
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
fo from automake-1.15
> Try `--no-discard-stderr' if option outputs to stderr
> make: *** [Makefile:3687: doc/automake-1.15.1] Fehler 255
Could you provide your config.log and the output of 'make V=1' and
'bin/automake --help'?
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
with the program is beyond me.
This quoting issue has only been fixed since Automake 1.15.1, so using
Automake with Perl 26 requires at least that Automake version.
If help is needed on GCC side to support newer version of Automake, feel
free to ask for help.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
egal advice (you won't find that on a volunteer
> mailing list).
Since this discussion is not related to an Automake bug, I will close it.
@Joël: If you have other questions regarding the licences of code
generated by automake or aclocal, please ask them on .
Thanks Nick for your explanat
toreconf: automake failed with exit status: 29
I would need more context. Could you give me some instructions to
reproduce this bug?
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Hello,
Moritz Klammler writes:
> On 09/15/2017 11:42 AM, Thomas Jahns wrote:
>> On 09/15/17 11:17, Mathieu Lirzin wrote:
>>> Instead of preemptively adding possible future version of Python that
>>> hopefully would be released, I would prefer a solution that remove
asedefs/V1_chap08.html#tag_08_03
>
> and look for "TZ".
Thanks for fixing that and for the reference.
> From 5b240b3b36766045a47a6ad89ae5f4550e81d534 Mon Sep 17 00:00:00 2001
> From: Paul Eggert
> Date: Thu, 21 Sep 2017 20:08:48 -0700
> Subject: [PATCH] * lib/mdate.sh (TZ): Use portable setting.
nitpick:
Hello,
Mathieu Lirzin writes:
> Right now we are using this branch naming scheme:
>
>- micro: for next micro version
>- minor: for next minor version
>- master: for next major version
>
> Given the current state of Automake I consider that the main scenario
Hello Eric,
Eric Dorland writes:
> This is a good change but it's not enough unfortunately to make it
> reproducible. mdate-sh also needs to support SOURCE_DATE_EPOCH. I'm
> working on a patch for that.
Thanks for working on that.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6
gt; ---
> lib/mdate-sh | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Applied with slight modifications in commit
7c25c996d1c7c212a5981aa0e9c4434b6f33f7b8
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Michael Haubenwallner writes:
> On 09/15/2017 11:00 AM, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>> On 08/27/2017 05:23 PM, Mathieu Lirzin wrote:
>>>>> From: Michael Haubenwallner
>>>>> Date: Wed, 16 Aug 2017 18:16:12 +0200
>
n that removes the
need to hard-code them.
WDYT?
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Michael Haubenwallner writes:
> On 08/27/2017 05:23 PM, Mathieu Lirzin wrote:
>
>>> From: Michael Haubenwallner
>>> Date: Wed, 16 Aug 2017 18:16:12 +0200
>>> Subject: [PATCH] automake: Depend on LIBOBJDIR for LIBOBJS.
>>>
>>> This change fixes
Michael Haubenwallner writes:
> On 08/27/2017 04:07 PM, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>> On 08/23/2017 11:24 PM, Mathieu Lirzin wrote:
>>>> Michael Haubenwallner writes:
>>>>> On 08/22/2017 12:40 AM, Mathieu Lirzi
POSIX, we also don't care.
> This is not a shortcoming that needs to be patched.
>
>> Maybe this would work instead:
>>
>> random=`dd 'if=/dev/urandom' 'count=1' 'bs=256' 2>/dev/null | cksum | sed
>> "$r"`\
>> `date -u | cksum | sed "$r"`
>
> No, there's no need to furrther complicate something that is already
> correct even when $RANDOM is empty.
I agree with Eric reasoning.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Michael Haubenwallner writes:
> On 08/24/2017 11:35 AM, Mathieu Lirzin wrote:
>
>> Instead of this dummy target, I would rather prefer adding the dirstamp
>> dependency for each explicit object file separately. this should be computed
>> from the '%libsources'
Michael Haubenwallner writes:
> On 08/23/2017 11:24 PM, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>> On 08/22/2017 12:40 AM, Mathieu Lirzin wrote:
>>>> Michael Haubenwallner writes:
>>>>
>>>>># If L
Nick Bowler writes:
> On 8/23/17, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>> Another thought about the final "$(LIBOBJS): .../.dirstamp" Makefile
>>> line: If I remember correctly, there have been (non-GNU) make
>>> implementat
Michael Haubenwallner writes:
> On 08/22/2017 12:40 AM, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>
>>> In this case let me come up with attached patch for now
>>> (without deeper knowledge of automake internals though).
>>
>> I have
Michael Haubenwallner writes:
> On 08/22/2017 12:23 AM, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>> On 08/17/2017 01:29 AM, Mathieu Lirzin wrote:
>>>> Michael Haubenwallner writes:
>>>>> On 08/08/2017 11:17 PM, Mathieu Lirzi
ar LIBOBJS (which might
># be created by libtool as a side-effect of creating LTLIBOBJS).
> - $clean_files{"\$($var)"} = MOSTLY_CLEAN if $var =~ s/^LT//;
> + if ($var =~ s/^LT//) {
> + $clean_files{"\$($var)"} = MOSTLY_CLEAN;
> + $output_rules .= "\$($var): $dirstamp\n" if ($dirstamp);
> + }
> }
>
>return $dir;
Thank you.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Michael Haubenwallner writes:
> On 08/17/2017 01:29 AM, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>> On 08/08/2017 11:17 PM, Mathieu Lirzin wrote:
>>>> Michael Haubenwallner writes:
>
>>>
>>> This change fixes automake bug#27781.
Hi,
Michael Haubenwallner writes:
> On 08/08/2017 11:17 PM, Mathieu Lirzin wrote:
>> Michael Haubenwallner writes:
>>>
>>> I have no idea for how to fix automake for this situation, but it
>>> feels like automake should add this line to src/Makefile.in h
le. Latest version of GNU Help2man [1] seems to already fix this
reproducibility issue [2]. So instead of applying your patch I have
simply upgraded the bundled script in commit
9322f409a957f153b38ff37ba79ddf4c19cff6ca.
Hopefully that will fix the issue. If that is not the case feel free to
. However I don't have time to investigate more right
now.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Mathieu Lirzin writes:
> Please avoid cross posting across mailing lists.
>
> Krishnan Rajiyah writes:
>
>> -- Forwarded message -
>> From: Krishnan Rajiyah
>> Date: Mon, Jun 29, 2015 at 10:40 AM
>> Subject: installation of automake, autoconf
ball, Unless something fishy happened
in the distribution process, Automake should not be required. Maybe you
were trying to build m4 from the git repository? I have successfully
built m4-1.4.18 tarball on my system without requiring Automake.
Thanks for the bug report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
demerphq writes:
> On 16 Jul 2017 01:50, "Mathieu Lirzin" wrote:
>
> Can you explain what would be the benefit for Automake to have such
> deterministic behavior?
>
> Thanks for the report.
>
> The most obvious reason is when debugging with something l
m?
>
> Thanks,
> Krishnan Rajiyah
Since in any case this is not related to an automake bug. I closing
this issue.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
bug#23602
[1] which has been fixed in Automake 1.15.1.
Feel free to open a new bug if the test suite fails for 1.15.1 on your
system.
Thanks for the bug report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23602
I think it would be nice to apply it and put up a 1.15.1 release because
> more and more people will hit this issue.
This has been fixed in Automake 1.15.1. I am closing this bug.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
prerequisites. So any lack of parallelism
seems related to some unnecessary prerequisites added in the provided
rules.
I am closing this bug since this seems like a bug in the Makefile you
have written not in Automake. Feel free to reopen it if you can provide
a minimal example demonstrating tha
o ensure that it functions correctly. The patch does
> not appear to affect any other modules when the
> entire test suite is run.
I think it would be nice add support for Genie in Automake.
Would you be willing to assign the copyright to the Free Software
Foundation, so that we could ins
aces('configure.ac') called at
> /usr/bin/automake line 5437
> Automake::scan_autoconf_files() called at /usr/bin/automake line 8259
> autoreconf: automake failed with exit status: 29
Can you provide a minimal way to reproduce this bug?
This seems to be the same issue a
r, the content of which I'll just cut and paste rather than
> attach. It's pretty simple...
This has been fixed in Automake 1.15.1
Thanks for the bug report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Hello,
Hans-Bernhard Bröker writes:
> Am 05.06.2017 um 00:24 schrieb Mathieu Lirzin:
>
>> I suspect this issue has already been fixed in the Git repository, see:
>>
>>
>> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro&id=13f00eb4493c21726
gt; and (I believe) should say:
>
> It’s worth noting that make distcheck needs complete control over
> the configure options
>
> (IOW s/nothing/noting).
This has been fixed in commit bea673a55bb7ae35933ff2c16ce10b32f476ba4e.
This will be updated in the web manual for the next rel
ake could as well look for at least
> upcoming 3.6 as well, there is certainly no harm in making a try.
This has been fixed by commit 87becfb21a35d79f32cb1af083124c8e116b1c2a.
Thanks for reporting this issue.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
rly test all of these changes,
> but superficial testing does not reveal any issues.
>
> Anyway, sorry for the misleading original bug-report.
>
> Cheers,
> Yves
Can you explain what would be the benefit for Automake to have such
deterministic behavior?
Thanks for the report.
--
M
ackages
having a Texinfo based documentation to require its contributors to have
'makeinfo' installed.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
t
> PASS: target.test
> PASS: target-cflags.test
> PASS: targetclash.test
> PASS: texinfo.test
> PASS: texinfo2.test
> PASS: texinfo3.test
> PASS: texinfo4.test
> PASS: texinfo5.test
> PASS: texinfo6.test
> PASS: texinfo7.test
> PASS: texinfo8.test
> PASS: texinfo9.test
> PASS: texinfo10.test
> SKIP: texinfo13.test
> SKIP: texinfo16.test
> FAIL: transform.test
> PASS: unused.test
> PASS: vars.test
> PASS: vars2.test
> PASS: vars3.test
> PASS: vartar.test
> PASS: version.test
> PASS: version2.test
> PASS: version3.test
> PASS: version4.test
> PASS: version5.test
> PASS: version6.test
> PASS: vpath.test
> PASS: vtexi.test
> PASS: vtexi2.test
> FAIL: warnopts.test
> PASS: werror.test
> PASS: whoami.test
> PASS: xsource.test
> PASS: yacc.test
> PASS: yacc2.test
> PASS: yacc3.test
> PASS: yacc4.test
> PASS: yacc5.test
> PASS: yacc6.test
> PASS: yacc7.test
> PASS: yacc8.test
> PASS: yaccpp.test
> PASS: yaccvpath.test
> =
> 33 of 423 tests failed
> (3 tests were not run)
> Please report to bug-automake@gnu.org
> =
> make[2]: *** [check-TESTS] Error 1
> make[2]: se sale del directorio «/home/javi/Escritorio/automake-1.7/tests»
> make[1]: *** [check-am] Error 2
> make[1]: se sale del directorio «/home/javi/Escritorio/automake-1.7/tests»
> make: *** [check-recursive] Error 1
Automake 1.7 is quite old so it is expected that some tests might fail.
As a consequence I am closing this bug. Feel free to reopen it if the
test suite still fails with 'Automake 1.15.1'.
Thanks for the bug report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
SABLE_HARD_ERRORS’ variable has no effect on them
>
> with
>
> for example, in tests using TAP, there is no way to disable hard
> errors, and the ‘DISABLE_HARD_ERRORS’ variable has no effect on them
This has been fixed in commit 5864fb5564a8607bf9a1fd90e12259127d8c629b.
Thanks for the report.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Hello,
Nick Brown writes:
> On Mon, 2017-06-05 at 00:45 +0200, Mathieu Lirzin wrote:
>>
>> Nick Brown writes:
>>
>> > Something like:
>> > ./autogen.sh
>> > ./configure
>> > make check-TESTS
>> > will f
1 - 100 of 129 matches
Mail list logo
