Re: Trying to bootstrap my project, distcheck doesn't configure

[Mathieu Lirzin]

Hello Bruce,

Bruce Korb  writes:

> In 9/9/20 11:37 AM, Bruce Korb wrote:
>> So in the years since I last rebuilt my project, it seems the world
>> has changed. What should I be looking for?
> OK. I've made some progress without any hints.

It would help if you could provide the instructions allowing others to
reproduce the problem you are facing.

> Now I'm hitting this
> that I've never seen before:
>> $ grep do_not_make_me au*bld/autoopts/Makefile.am
>> do_not_make_me_la_LIBADD += @LTALLOCA@
>> do_not_make_me_la_DEPENDENCIES += @LTALLOCA@
>> EXTRA_do_not_make_me_la_SOURCES += alloca.c
>> EXTRA_do_not_make_me_la_SOURCES += dup2.c
>> do_not_make_me_la_SOURCES += fd-hook.c
>> do_not_make_me_la_SOURCES += gettext.h
>> EXTRA_do_not_make_me_la_SOURCES += msvc-inval.c
>> EXTRA_do_not_make_me_la_SOURCES += msvc-nothrow.c
>> EXTRA_do_not_make_me_la_SOURCES += nanosleep.c
>> do_not_make_me_la_SOURCES += parse-duration.c
>> EXTRA_do_not_make_me_la_SOURCES += raise.c
>> EXTRA_do_not_make_me_la_SOURCES += select.c
>> do_not_make_me_la_SOURCES += sig-handler.c
>> EXTRA_do_not_make_me_la_SOURCES += sigaction.c
>> EXTRA_do_not_make_me_la_SOURCES += sigprocmask.c
>> do_not_make_me_la_SOURCES += sockets.h sockets.c
>> do_not_make_me_la_SOURCES += stat-time.c
>> do_not_make_me_la_SOURCES += sys_socket.c
>> do_not_make_me_la_SOURCES += timespec.c
>> do_not_make_me_la_SOURCES += unistd.c
> which trigger error messages that I can get around by hacking in dummy
> initial assignments, but I'm guessing that's not the intended
> method. I need a clue, please? Thank you.

Dummy initial assignments is a valid fix if you want/need to dispatch
your source definitions in multiple files without having to care about
the inclusion order.  Alternatively you can define all your sources in
one go in one file like this:

do_not_make_me_la_SOURCES = \
  sockets.h \
  sockets.c \
  stat-time.c \
  sys_socket.c \
  timespec.c \
  unistd.c

>> autoopts/Makefile.am:97: error: do_not_make_me_la_LIBADD must be set
>> with '=' before using '+='
>> autoopts/Makefile.am:98: error: do_not_make_me_la_DEPENDENCIES must
>> be set with '=' before using '+='
>> autoopts/Makefile.am:100: error: EXTRA_do_not_make_me_la_SOURCES
>> must be set with '=' before using '+='
>> autoopts/Makefile.am:146: error: do_not_make_me_la_SOURCES must be
>> set with '=' before using '+='
>> autoopts/Makefile.am:390: error: MOSTLYCLEANDIRS must be set with
>> '=' before using '+='
>> autoopts/Makefile.am:100: warning: variable
>> 'EXTRA_do_not_make_me_la_SOURCES' is defined but no program or
>> autoopts/Makefile.am:100: library has 'do_not_make_me_la' as
>> canonical name (possible typo)
>> autoopts/Makefile.am:146: warning: variable
>> 'do_not_make_me_la_SOURCES' is defined but no program or
>> autoopts/Makefile.am:146: library has 'do_not_make_me_la' as
>> canonical name (possible typo)
>> autoopts/Makefile.am:97: warning: variable
>> 'do_not_make_me_la_LIBADD' is defined but no program or
>> autoopts/Makefile.am:97: library has 'do_not_make_me_la' as
>> canonical name (possible typo)
>> autoopts/Makefile.am:98: warning: variable
>> 'do_not_make_me_la_DEPENDENCIES' is defined but no program or
>> autoopts/Makefile.am:98: library has 'do_not_make_me_la' as
>> canonical name (possible typo)

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED

[Mathieu Lirzin]

Hello Karl,

Mathieu Lirzin  writes:

> Karl Berry  writes:
>
>> Other than that, please push asap! --thanks again, karl.
>
> I Will push that patch before the end of the week.

Done in commit f19ecc089b017d0f0cde1e960fb1a6a407005164.

Thanks for the review.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED

[Mathieu Lirzin]

Hello Karl,

Karl Berry  writes:

> Hi Mathieu - I'm glad you replied. I saw in the ChangeLog that you
> created AUTOMAKE_UNINSTALLED :). The general idea was clear, but all the
> implications, not so much.
>
> Here is a patch that seem to fix the issue, I have added some clutter to
> AM_TESTS_ENVIRONMENT 
>
> Thanks! make distcheck now passes completely, all three failing tests
> are fixed, with both python2 and python3. That is great.
>
> The only trivial thing I would ask is that I would appreciate not
> breaking new ground with the UTF-8 quotes in the comment, since they are
> not really necessary (the comment is just as understandable with no
> quote characters, or '...' if you prefer). There are no UTF-8 quotes in
> the main source files now.
> +# the €˜pre-inst-env€™ wrapper script.

Sure that was not intentional.

> Other than that, please push asap! --thanks again, karl.

I Will push that patch before the end of the week.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED

[Mathieu Lirzin]

Hello Karl,

Karl Berry  writes:

> The aclocal-print-acdir.sh test fails at the make installcheck step of
> make distcheck (it succeeds in the normal make check, and it succeeds at
> the make check of make distcheck; only fails in the make installcheck).
>
> This is because AUTOMAKE_UNINSTALLED is (correctly) set in the
> environment at that point, which causes aclocal-1.16 --print-ac-dir
> to forcibly return the empty string, which does not match the expected
> acdir string:
>
>   + aclocal-1.16 -Werror --print-ac-dir
>
>   test "$($ACLOCAL --print-ac-dir)" = "$am_system_acdir"
>   ++ aclocal-1.16 -Werror --print-ac-dir
>   + test '' = /u/karl/gnu/src/akarl/automake-1.16a/_inst/share/aclocal
>   am_exit_trap $?
>   + am_exit_trap 1
>
> Per this bit in the aclocal-1.16 Perl script:
>
>   if (exists $ENV{"AUTOMAKE_UNINSTALLED"})
> {
>   @automake_includes = ();
>   @system_includes = ();
> }
>
> (The --print-ac-dir option simply prints the value of @system_includes.)
>
> So, if I unset AUTOMAKE_UNINSTALLED in the test, it works:
> test "$am_running_installcheck" = yes && unset AUTOMAKE_UNINSTALLED || :
>
> Since this test is intended to check exactly a value that only is set
> normally in an installation, that seems like a reasonable thing to do.
>
> But I am not sure. Jim, anyone with more experience, can you confirm/deny?

The AUTOMAKE_UNINSTALLED environment variable along side the
“pre-inst-env” wrapper script were introduced to isolate srcdir and
builddir environment from installdir while not having to patch the
source code at install time. This follows a pattern I discovered in the
Guix package and ported to Automake and Texinfo.

To fix ‘make installcheck’ I think it would make sense to remove the
usage of the “pre-inst-env” script in that context because as its name
suggest this is a "pre-inst{allation}-env{ironment}". Concretely This
means overriding LOG_COMPILER and PL_LOG_COMPILER and ensuring that the
installed perl modules are found for the tests.

Here is a patch that seem to fix the issue, I have added some clutter to
AM_TESTS_ENVIRONMENT which is not ideal but was less work than migrating
everything to a “test-env” wrapper script which would probably improve
readability.

What do you think?

It is nice to see some activity on Automake. :-)

>From 49a02b8ce3e1e2475ec51e432806c9fb8eb743e5 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Tue, 4 Feb 2020 15:28:00 +0100
Subject: [PATCH] =?UTF-8?q?build:=20fix=20=E2=80=98installcheck=E2=80=99?=
 =?UTF-8?q?=20target?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* t/local.mk (installcheck-testsuite): Do not use "pre-inst-env" script.
(AM_TESTS_ENVIRONMENT): Ensure that installed perl modules are found.
---
 t/local.mk | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/t/local.mk b/t/local.mk
index 7e3a61965..06ed70d0e 100644
--- a/t/local.mk
+++ b/t/local.mk
@@ -244,12 +244,22 @@ check-parallel:
 test_subdirs = %D% %D%/pm contrib/%D%
 include %D%/CheckListOfTests.am
 
-# Run the testsuite with the installed aclocal and automake.
+# Run the testsuite with the installed aclocal and automake without using
+# the ‘pre-inst-env’ wrapper script.
 installcheck-local: installcheck-testsuite
 installcheck-testsuite:
 	$(AM_V_GEN)$(MAKE) $(AM_MAKEFLAGS) check \
+	  LOG_COMPILER=$(AM_TEST_RUNNER_SHELL) \
+	  PL_LOG_COMPILER=$(PERL) \
 	  am_running_installcheck=yes
 
+# Ensure that the installed Automake perl modules are found when running 'installcheck' target
+AM_TESTS_ENVIRONMENT += \
+  if test "$${am_running_installcheck}" = yes; then \
+PERL5LIB="$(DESTDIR)$(pkgvdatadir)/$${PERL5LIB:+$(PATH_SEPARATOR)}$$PERL5LIB"; \
+  fi; \
+  export PERL5LIB;
+
 # Performance tests.
 .PHONY: perf
 perf: all
-- 
2.20.1


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

[Mathieu Lirzin]

Hello Jim,

Jim Meyering  writes:

> Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
> Another reference to the problem: http://bugs.gnu.org/36921
>
> In the attached (in Gavin's name), I've added a NEWS entry and
> adjusted the ChangeLog entry. Will push in a day or so if no comment.

Thanks for taking care of this. :-)

> From 309a6c477eec80b847078699303c65ccd7787eb0 Mon Sep 17 00:00:00 2001
> From: Gavin Smith 
> Date: Sun, 25 Aug 2019 21:07:58 -0700
> Subject: [PATCH] automake: do not require @setfilename in Texinfo files
>
> Texinfo no longer requires a @setfilename directive in each
> .texi file, so automake now also relaxes its restriction.
> * bin/automake.in (scan_texinfo_file): Derive name of info file from
> name of input file if no @setfilename line occurs in the file.
> * t/txinfo-no-setfilename.sh: New test.
> * t/list-of-tests.mk: Add it.
> * NEWS: Mention it.
>
> Fixes automake bugs #36921 and #34201.
> ---

Not really important but HACKING 
recommends a slightly different style.

--8<---cut here---start->8---
  topic: brief description (this is the "summary line")

  

  Here goes a more detailed explanation of why the commit is needed,
  and a general overview of what it does, and how.  This section
  should almost always be provided, possibly only with the expection
  of obvious fixes or very trivial changes.

  And if the detailed explanation is quite long or detailed, you can
  want to break it in more paragraphs.

  Then you can add references to relevant mailing list discussions
  (if any), with proper links.  But don't take this as an excuse for
  writing incomplete commit messages!  The "distilled" conclusions
  reached in such discussions should have been placed in the
  paragraphs above.

  Finally, here you can thank people that motivated or helped the
  change.  So, thanks to John Doe for bringing up 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

Re: [PATCH] automake: do not require @setfilename in Texinfo files

[Mathieu Lirzin]

Hello Jim,

Jim Meyering  writes:

> Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
> Another reference to the problem: http://bugs.gnu.org/36921
>
> In the attached (in Gavin's name), I've added a NEWS entry and
> adjusted the ChangeLog entry. Will push in a day or so if no comment.

Thanks for taking care of this. :-)

> From 309a6c477eec80b847078699303c65ccd7787eb0 Mon Sep 17 00:00:00 2001
> From: Gavin Smith 
> Date: Sun, 25 Aug 2019 21:07:58 -0700
> Subject: [PATCH] automake: do not require @setfilename in Texinfo files
>
> Texinfo no longer requires a @setfilename directive in each
> .texi file, so automake now also relaxes its restriction.
> * bin/automake.in (scan_texinfo_file): Derive name of info file from
> name of input file if no @setfilename line occurs in the file.
> * t/txinfo-no-setfilename.sh: New test.
> * t/list-of-tests.mk: Add it.
> * NEWS: Mention it.
>
> Fixes automake bugs #36921 and #34201.
> ---

Not really important but HACKING 
recommends a slightly different style.

--8<---cut here---start->8---
  topic: brief description (this is the "summary line")

  

  Here goes a more detailed explanation of why the commit is needed,
  and a general overview of what it does, and how.  This section
  should almost always be provided, possibly only with the expection
  of obvious fixes or very trivial changes.

  And if the detailed explanation is quite long or detailed, you can
  want to break it in more paragraphs.

  Then you can add references to relevant mailing list discussions
  (if any), with proper links.  But don't take this as an excuse for
  writing incomplete commit messages!  The "distilled" conclusions
  reached in such discussions should have been placed in the
  paragraphs above.

  Finally, here you can thank people that motivated or helped the
  change.  So, thanks to John Doe for bringing up 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

Re: Automake 1.16.1: problem with non-gnu make and gnulib

[Mathieu Lirzin]

Assaf Gordon  writes:

> Issue solved!
>
> Thanks to Bruno Haible in
> https://lists.gnu.org/r/bug-gnulib/2019-08/msg00064.html
>
> Quoting that message (and my reply):
> ---
> On 2019-08-24 3:36 p.m., Bruno Haible wrote:
>> I think the problem is that 'bmake' does not consider the targets
>> 'foo' and './foo' as being the same.

Excellent! :-)

> And indeed,
>
> GNU hello and GNU datamash (which exhibit the problem)
> have something like this in their Makefile.am:
>
>  hello_LDADD =  $(top_builddir)/lib/lib$(PACKAGE).a
>  datamash_LDADD =  $(top_builddir)/lib/lib$(PACKAGE).a
>
> While sed and coreutils (which don't have the problem) have:
>
>   sed_sed_LDADD = sed/libver.a lib/libsed.a
>   LDADD = src/libver.a lib/libcoreutils.a
>
> So because of the "$(top_builddir)" the targets gets a "./"
> prefix, and combined with that recent automake change,
> they ended up being considered separated targets by "bmake".
> ---
>
> So the immediate fix/work-around is to remove any path from
> the libraries listed in xxx_LDADD in the projects themselves.
>
> However,
> This change (regression?) seems to come from automake, perhaps
> consider a bugfix for future versions.

Unfortunately I currently don't have much time for Automake.

If somebody is willing to do the investigation job and fix the code, I
am willing to apply the patch.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Automake 1.16.1: problem with non-gnu make and gnulib

[Mathieu Lirzin]

Hello Assaf,

Assaf Gordon  writes:

> On 2019-08-24 7:34 a.m., Bob Friesenhahn wrote:
>> On Sat, 24 Aug 2019, Assaf Gordon wrote:
>
>>>
>>> I've encountered a problem where a released tarball (of 'make dist')
>>> generated by Automake-1.16.1 fails to build with non-gnu make (e.g.
>>> "bmake" on BSDs).
>>> The exact same project and 'make dist' with automake-1.15 builds fine.
>>
>> The problem may very well have to do with parts obtained from gnulib
>> or an implementation artifact from the template Makefiles.
>
> I certainly agree - but it seems like a regression in Automake where
> a structure that worked for several years (and several automake
> versions) now stopped working.
>
> I'm looking for any hints or ideas as to what changed or what is causing
> the failure...

One convenient way to detect what caused this problem would be to do a
‘git bisect’ session on Automake VCS repository and analyse the diff of
the commit introducing the failure.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Mathieu Lirzin]

Hello Stuart,

Stuart Caie  writes:

> the automake macro AM_ICONV requires the auxiliary program config.rpath,
> however automake --add-missing will not install it.
>
> Technically, AM_ICONV is not distributed with automake, and neither is
> is config.rpath. However, automake recognises config.rpath as a special
> file to distribute nonetheless.
>
> Could config.rpath be added to automake's list of auxiliary programs,
> like ar-lib, config.guess and so on?
>
> If not, could there be some mechanism added to automake so other
> packages can tell it to add their required files? e.g. could gettext.m4
> which defines AM_ICONV include some special macro that tells automake
> that config.rpath is needed and can be found in  ?

“config.rpath” which is maintained in GNU Gettext is already copied
inside the target source tree by the ‘autopoint’ program which is
automatically run by ‘autoreconf --install’ when the Gettext macros are
added to “configure.ac”.  ‘autoreconf’ serves as a meta command for the
autotools which should be used instead of manually running ‘autoconf’,
‘aclocal’, ‘automake’, ... in sequence.

Unless you disagree, I will close this bug.

Thanks for the report.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#32150: Acknowledgement (Suggested Texinfo Source Corrections)

[Mathieu Lirzin]

Hello Paul,

Paul Hardy  writes:

> I had made my corrections on a hard copy and then entered them into
> the computer.  There were two typos that I remembered seeing when I
> read the document but didn't recall entering yesterday, and indeed I
> had not entered them.  Here they are.

Both patches were applied in commit 6624f88b2ea685e5c44c7373d01df488d1dabd19.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#33029: AM_LFLAGS --prefix option breaks build-aux/ylwrap script

[Mathieu Lirzin]

Hello Sjoerd,

Sjoerd van Leent  writes:

> Using Automake 1.15.1, I attempted to create a prefix other than the
> default "yy" for usage of the Fast Lexical Analyzer Generator. The
> FLEX arguments used for this, can be set using Automake option
> AM_LFLAGS and friends. Doing this with the --prefix argument however,
> causes a side-effect which the ylwrap script fails to act on. The
> option does not only replace yy inside the generated lex.yy.c file,
> but also changes lex.yy.c to become lex..c. This behavior
> breaks the ylwrap script, as it can no longer find lex.yy.c and
> therefore no longer move and rename it to the proper location
> (breaking the build process).
>
> I managed my way around this, by forcing flex to generate a lex.yy.c
> file (adding -o lex.yy.c also to AM_LFLAGS). The solution to my mind
> is simple: if --prefix is used in the AM_LFLAGS and friends option,
> the ylwrap script should either expect this new prefix as a
> replacement token of the "yy" part of lex.yy.c, or ylwrap should add
> -o lex.yy.c on it's own initiative.
>
> I hope that you are able to aid in repairing this 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

bug#33085: using myprog_CXXFLAGS with VPATH prevents Makefile from finding sources

[Mathieu Lirzin]

Hello Nick,

Nick Bowler  writes:

> On 10/18/18, Julien COURTAT  wrote:
>> Here's my bug report, I'm building my software out of the source tree, this
>> is called parallel build (very nice feature).
>> The way to reproduce the issue is very simple, set myprog_CXXFLAGS = -DANY
>> and VPATH=@MYDIR@ and the corresponding Makefile won't find my source file.
>> Replace myprog_CXXFLAGS by AM_CXXFLAGS and it works well.
>> Autoconf 2.69, automake 1.13.4
> [...]
>> Makefile.am :
>> bin_PROGRAMS=myprog
>> myprog_SOURCES  = 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

bug#33022: Generated Makefile builds PROGRAMS before LTLIBRARIES

[Mathieu Lirzin]

Hello,

Mohamed Akram  writes:

> automake’s behavior seems to have changed between 1.15.1 and 1.16.1: 
>
> 1.15.1:
>
> all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) config.h
>
> 1.16.1:
>
> all-am: Makefile $(PROGRAMS) $(LTLIBRARIES) $(HEADERS) config.h
>
> This causes an automake file which builds a library and a program that uses 
> that library to fail.
>
> An example can be seen here - 
> https://github.com/codebrainz/morse/issues/1#issuecomment-429200053.

The fact that when running ‘make’ in serial, some prerequisites of a
make rule are built before other ones is undefined behavior.  Relying on
this when running ‘make’ in parallel mode is likely to result in a build
failure.

what needs to be done in ‘codebrainz’ is to add an explicit dependency
between programs and the libraries they depend on. See the following
example from 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

Re: [PATCH] t/pm: Use Test::Simple for Perl tests

[Mathieu Lirzin]

Matthias Paulmier  writes:

> I sure can, I was feeling like it was a bit long but for some reason
> thought it was better that way.

No problem, the appropriate granularity for patches is a subjective
matter.  However in practice software projects tend to agree that new
features, bug fixes, and file renaming/moving should be done in
separated commit/patches.

> Can I send multiple patches at once (in one email as attachements), or
> should I send them each on their own?

Both are possible, and convenient for me.

To be more precise, if you do it by hand with attachments, it will be
simpler to include all those attachments in one email.

Alternatively If you use ‘git send-email’, by default it sends the
patches in response to the first patch or the “cover letter” if you made
one.  In your case you it is important to add the
‘--in-reply-to="<878t4fhddt@mpaulmier.home>"’ option to ensure that
your first patch is sent in response to the current thread.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH] t/pm: Use Test::Simple for Perl tests

[Mathieu Lirzin]

Hello Matthias,

Matthias Paulmier  writes:

> This patch enables the use of the Test::Simple (and Test::More) library
> for the Perl lib tests.  One point that may need reflexion is wether or
> not to keep the "old" way of testing Perl libraries into Automake (that
> is without using Test::Simple/More).
>
> This patch is part of my GSoC project.  I am sorry it took so long and
> will make sure to submit the rest of my modifications in the comming days.

This is already a big chunk to review so please wait for this patch to
be reviewed and applied before sending the other ones.  ;-)

> From b0a682a918242b3a74147cd60aadf4e543eb5ce0 Mon Sep 17 00:00:00 2001
> From: Matthias Paulmier 
> Date: Thu, 30 Aug 2018 16:30:19 +0200
> Subject: [PATCH] t/pm: Use Test::Simple for the tests of the Perl libraries
>
> This allows to have more tests using the TAP protocol for tests.  We can also
> use other libraries such as Test::More.  For these tests, we use a new
> extension (.plt) for those tests.  This change does not exclude the "old" way
> of doing things as the .pl extension still exists in t/local.mk in case
> someone wants to test the old way.
>
> * t/pm: Use eval to fix fail XFAIL perl test and catch fatal errors.
> * t/pm: Regroup tests by module (consequence of the above).
> * t/pm: Add a new extension for Perl tests using Test::Simple (.plt).
> * t/pm: Move all current tests to the .plt extension.
> * lib/Automake: Move END to its own submodule to fix a termination bug with
>   Test::Simple where STDOUT was closed and then reopened.
> ---
>  bin/aclocal.in|   1 +
>  bin/automake.in   |   1 +
>  lib/Automake/End.pm   |  47 +++
>  lib/Automake/General.pm   |  24 +---
>  lib/Automake/local.mk |   1 +
>  t/list-of-tests.mk|  33 ++---
>  t/local.mk|   4 +-
>  t/pm/Cond2.pl |  22 
>  t/pm/Cond3.pl |  22 
>  t/pm/{Condition-t.pl => Condition-t.plt}  |  12 +-
>  t/pm/{Condition.pl => Condition.plt}  |  34 -
>  t/pm/DisjCon2.pl  |  24 
>  t/pm/DisjCon3.pl  |  23 
>  ...sjConditions-t.pl => DisjConditions-t.plt} |  12 +-
>  .../{DisjConditions.pl => DisjConditions.plt} |  36 +-
>  t/pm/{General.pl => General.plt}  |  10 +-
>  t/pm/Version.pl   | 112 
>  t/pm/Version.plt  | 122 ++
>  t/pm/Version2.pl  |  20 ---
>  t/pm/Version3.pl  |  20 ---
>  t/pm/{Wrap.pl => Wrap.plt}|  23 ++--
>  21 files changed, 277 insertions(+), 326 deletions(-)

This patch is too fat for me to properly review it.  The changelog
description makes me think it could easily be separated in smaller
chunks.  For example you could make one patch adding support for
‘Test::Simple’ and a basic test file with a ‘.plt’ extension, one patch
for each test file migrated to Test::Simple, one for fixing the XFAIL
hack...

Feel free to adapt to your particular case, since you understand the
dependencies between the change you made better than I do.

Can you send the updated patches?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: copyright problem with install-sh, request for clean-room rewrite

[Mathieu Lirzin]

Hello Eric,

Eric Blake  writes:

> This is contradictory, and needs to be fixed in the Autoconf
> manual. However, the question on the floor is whether the fix is
> merely rewording that sentence to describe the actual copyright and
> permissive license, or if a better fix might be possible, such as
> rewriting 'install-sh' from scratch so that we can ship a version of
> the file that is completely copyright FSF and therefore uses the
> identical GPLv3+exception as the rest of the files we care about,
> rather than having to play the legal games of whether the X Consortium
> copy introduces any wrinkles in the first place.

Given the small size of this script it seems a reasonable option to
rewrite it from scratch, to avoid the license mess.

> Is anyone willing to take on a clean-room reimplementation of the
> functionality of install-sh?  If so, I can write up a list of
> requirements for what your implementation must provide; you must write
> a shell script that has that functionality, and without using any
> reference to the existing install-sh file, and where your work can
> have copyright assigned to FSF; but you can use GNU Coreutils' install
> program for a reference on functionality questions (I consider myself
> ineligible for such a clean-room reimplementation, since I am one of
> the people that has already made edits to the 'install-sh' belonging
> to Automake, but I have no qualms in reviewing your work for accuracy
> and portability).

According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.
Your help regarding ‘install-sh’ requirements analysis and code review
would indeed be welcome.  Regarding the requirements I guess Automake
test suite already contains some tests validating some of them.

WDYT?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] "Modularize Automake" Final Report

[Mathieu Lirzin]

Hello Matthias,

Matthias Paulmier  writes:

>   This summer has overall been a great experience for me as I have
>   learned a lot about Perl and tests in general.  This was a big
>   challenge for me as I have never worked on such a large code base (it
>   may not be much for others but it was quite a significant one for me).
>   As we have seen above, the project still needs some work as I have
>   said previously.
>
>   As you may know if you follow this list, Mathieu is stepping down as
>   maintainer of Automake.  The code produced this summer will therefore
>   not be integrated into the project until someone is taking on that
>   role and is willing to review the changes.
>
>   I am not aware of anyone taking on the role of maintainer of Automake
>   so far but, when this person is there, I am willing to work with them
>   to be able to integrate my code into Automake as well as improving or
>   expanding it (while I will not be as available as this summer i am
>   still willing to contribute).  Be it partially or in its entirety.  I
>   think some parts could be very interesting for the project.
>   Especially the fix of the Perl `XFAIL' tests and the use of the
>   `Export' module inside Automake.

I really enjoyed reading your detailed and honest report, and even if I
have not been able to follow the second half of the coding period in
details, I am pleased with the work you have done.

Even if I stepped down I am still a commiter, so there is nothing
besides time which prevents me from integrating your work in particular
if those changes are safe.  In theory, refactoring work can easily be
reviewed if for example you create one patch for each module extracted
with its corresponding test.  I recommend to submit those patches
incrementally to .

Thank you for your participation in the GSoC!

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Stepping down

[Mathieu Lirzin]

Hello,

I will be starting a PhD thesis by the end of the year.  While preparing
myself for this new challenge, I feel like my maintainer role for
Automake, Mcron, and Freetalk cannot be fulfilled correctly anymore.  As
a consequence I have decided to step down.

Regarding my involvement in the mentoring of the two Automake GSoC
students, I will continue to assume that role until the end of the
summer.

I wish the best for the future of those packages.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#31222: automake 1.16.1 am__pep3147_tweak bug

[Mathieu Lirzin]

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

bug#32074: maintainer-clean and removing configure/Makefile.in/etc.

[Mathieu Lirzin]

Karl Berry  writes:

> I think Automake shouldn't suggest something that is explicitly
> discouraged by the GCS.
>
> Good point. I agree.
>
> I would suggest discussing it on ...
>
> Perfectly reasonable, but I'm just too old to have the stomach 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 your mind.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH 2/2] python tests: Do not require .pyo files

[Mathieu Lirzin]

Mathieu Lirzin  writes:

> Lukas Fleischer  writes:
>
>> On Sat, 07 Jul 2018 at 23:45:27, Mathieu Lirzin wrote:
>>> Lukas Fleischer  writes:
>>> 
>>> > As of Python 3.5, but unoptimized and optimized bytecode are stored
>>> > within .pyc files; .pyo files are no longer generated. Update the Python
>>> > tests such that the test do not fail if .pyo files are missing.
>>> 
>>> Like in other message, it is important that the test suite passes
>>> with older python version.  Have you checked?
>>
>> Note that this patch only removes some checks, so after this patch,
>> everything is strictly less restrictive. I don't see how this could
>> possibly break backwards compatibility.
>>
>> Nevertheless, I just made sure that everything still works with Python
>> 2.7.15.
>
> OK I overlooked that.  I think a inlined comment in the concerned tests
> explaining why python object files presence is not tested would help
> future code reader to understand.
>
> Can you send an updated patch?

Please forget the updated patch fornow.  I have just remember about
about bug#30556 [1] where test suite is known to fail when ‘python’ is
‘python3’ and not ‘python2’ which is the case on Arch Linux.  Sorry for
the confusion.

You seem to have a better understanding of how various version of python
handles compilation and caches than I do.  Maybe can you summarize (give
some pointers)  the various evolution in that regard?

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30556

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH 2/2] python tests: Do not require .pyo files

[Mathieu Lirzin]

Lukas Fleischer  writes:

> On Sat, 07 Jul 2018 at 23:45:27, Mathieu Lirzin wrote:
>> Lukas Fleischer  writes:
>> 
>> > As of Python 3.5, but unoptimized and optimized bytecode are stored
>> > within .pyc files; .pyo files are no longer generated. Update the Python
>> > tests such that the test do not fail if .pyo files are missing.
>> 
>> Like in other message, it is important that the test suite passes
>> with older python version.  Have you checked?
>
> Note that this patch only removes some checks, so after this patch,
> everything is strictly less restrictive. I don't see how this could
> possibly break backwards compatibility.
>
> Nevertheless, I just made sure that everything still works with Python
> 2.7.15.

OK I overlooked that.  I think a inlined comment in the concerned tests
explaining why python object files presence is not tested would help
future code reader to understand.

Can you send an updated patch?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH 2/2] python tests: Do not require .pyo files

[Mathieu Lirzin]

Lukas Fleischer  writes:

> As of Python 3.5, but unoptimized and optimized bytecode are stored
> within .pyc files; .pyo files are no longer generated. Update the Python
> tests such that the test do not fail if .pyo files are missing.

Like in other message, it is important that the test suite passes
with older python version.  Have you checked?

> * t/py-compile-basedir.sh: Remove all .pyo checks.
> * t/py-compile-basic.sh: Likewise.
> * t/py-compile-destdir.sh: Likewise.
> * t/py-compile-option-terminate.sh: Likewise.
> * t/python-virtualenv.sh: Likewise.
> * t/python10.sh: Likewise.
> * t/python12.sh: Likewise.
> * t/python3.sh: Likewise.
> ---
>  t/py-compile-basedir.sh  |  2 --
>  t/py-compile-basic.sh|  3 ---
>  t/py-compile-destdir.sh  | 12 +---
>  t/py-compile-option-terminate.sh |  5 -
>  t/python-virtualenv.sh   |  4 
>  t/python10.sh|  6 --
>  t/python12.sh|  3 +--
>  t/python3.sh |  1 -
>  8 files changed, 6 insertions(+), 30 deletions(-)

Thanks for the patch.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH 1/2] python: Properly uninstall __pycache__ in subdirectories

[Mathieu Lirzin]

Lukas Fleischer  writes:

> When uninstalling __pycache__ files in a subdirectory "sub", the
> Makefile incorrectly removed the files from __pycache__/sub/ instead of
> sub/__pycache__/.
>
> * lib/am/python.am (uninstall-%DIR%PYTHON): Use the correct path when
> installing byte-compiled files installed in '__pycache__'
> subdirectories.

Tell me if I am overlooking something, but I guess this change will
imply that the uninstallation does not properly work with older python
version?  Have you tried?

This support is important in the context of Automake.

Thanks for the patch.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#32074: maintainer-clean and removing configure/Makefile.in/etc.

[Mathieu Lirzin]

Hello Jack,

Jack Kelly  writes:

> Karl Berry  writes:
>
>> [snip automake manual blockquote]
>>
>> But nowadays, especially since autoreconf exists, it does not seem
>> unreasonable to me to want to delete Makefile.in, configure, etc. It
>> is just as easy to run autoreconf (or equivalent) as configure&,
>> and it feels nice to have such dependent files gone from the source
>> tree, especially when working on setting up a package with autotools.
>>
>> I certainly don't suggest changing any behavior, but perhaps the manual
>> could mention that it could be done via maintainer-clean-local or
>> MAINTAINERCLEANFILES, 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...
>
> It is certainly valuable to test that you can bootstrap your package
> from autoreconf up, but I don't think `make maintainer-clean' is the
> best place to do that. The `git-clean' command removes untracked files
> from the worktree, and I'm sure other VCSes let you do similar
> things. Maybe the manual could point to those commands?

This works only when files generated by Autotools are not commited to
VCS.  Having said that, I agree this is a general good practice that
ought to be documented 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

Re: How to run the autoconf generated testsuite with `make installcheck`?

[Mathieu Lirzin]

Hello Simon,

Simon Sobisch  writes:

> While the automake manual mentions the installcheck target it doesn't
> leave a note where to find more information about this.
>
> I assume this is about something like:
>
> * adding a installcheck-local target to tests/Makefile.am
> * in this target run the check-local target but set an environment
> variable before
> * in tests/atlocal.in check for this variable and adjust the path of the
> tested binaries to use no path at all (=use the ones found in PATH)
>
> Is this the correct approach?
>
> Thank you for providing some experience / best practice about the
> installcheck target,

I don't have much experience with ‘installcheck’ target.  I have used it
in GNU Mcron to check the location and basic properties of the installed
files [1].

I would recommend against running unit tests on the installed program
and reserve it for validation tests.  For example verifying that default
paths values are properly set to the installed location which can't be
checked from ‘builddir’.

[1] https://git.savannah.gnu.org/cgit/mcron.git/tree/Makefile.am

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: How to move aminfo-results (PDF/HTML) from clean-aminfo to maintainer-clean-aminfo?

[Mathieu Lirzin]

Hello Simon,

"Simon Sobisch"  writes:

>GnuCOBOL includes the manual in both info and PDF formats in its
>tarballs, but the PDF is removed on `make clean`.
>
>This is the main part of doc/Makefile.am:
>
>_
>
>info_TEXINFOS = gnucobol.texi
>gnucobol_TEXINFOS = fdl.texi
>EXTRA_DIST = gnucobol.pdf
>AM_MAKEINFOHTMLFLAGS = --no-headers --no-split
>CLEANFILES = *.aux  *.cp *.fn *.ky *.log *.pg *.toc *.tp *.vr *.vrs
>TEXI2DVI = texi2dvi -I $(srcdir)
>_
>
>This is the current behavior:
>
>* `make dist`creates .info and .pdf, both are included in the
>tarball
>* `make clean`   removes .pdf
>* `make maintainer-clean`   removes .info
>
>Therefore the purpose of EXTRA_DIST "the user doesn't need to have the
>tools installed to create the file"
>only works as long as he doesn't call `make clean`.
>
>I've checked the generated Makefile.in and indeed it has
>
>clean-aminfo:
>-test -z "gnucobol.dvi gnucobol.pdf gnucobol.ps gnucobol.html" \
>|| rm -rf gnucobol.dvi
>
>
>Is there an option to move gnucobol.pdf (and ideally gnucobol.html,
>too) from clean-aminfo to maintainer-clean-aminfo?

Automake assumes that only info files are distributed as stated by
Automake manual [1].  This is the reason why only info files are built
in ‘srcdir’ and not the other formats.

While IMO it would be nice to support distribution of arbitrary
documentation output formats, I would expect such feature to be far from
trivial to implement.

The strategy of checking ‘EXTRA_DIST’ for matching file names
corresponding to distributed format seems a nice workaround, however it
would need more consideration regarding the potential issues this
solution might bring (in particular the ‘srcdir’ thing).

So What I recommend for now would be for GNUCobol to not distribute PDF
file for the sake of simplicity and robustness.  On the Automake side
what seems appropriate for such issue is to open a “wishlist” bug.

WDYT?

[1] https://www.gnu.org/software/automake/manual/html_node/Texinfo.html

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Reafactoring Automake: Report

[Mathieu Lirzin]

Matthias Paulmier  writes:

> In the last email I forgot to mention the repository and branch I will
> be working on.
>
> The repo is of course <http://git.savannah.gnu.org/cgit/automake.git>
> and I'm on the experimental/gsoc/refactoring branch.
>
> Not much has been done until today on the branch but it should be fairly
> busy in the next couple of weeks.

Great, I will follow that.  :-)

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Proposal Accepted for GSoC

[Mathieu Lirzin]

Hello Vishal,

Vishal Gupta <vishalgupta7...@gmail.com> writes:

> My proposal for the project " Parse Makefile.am using abstract syntax
> tree" has been accepted and I am excited to start working on the same.

Congrats!

> The community bonding period will be till 14th May. As discussed in
> the proposal, I will be working on improving my perl skills and
> understanding the Automake's Code. Some queries about that :
>
> 1) Good resource for studying Perl and important concepts required for
> completing the project. A short task of 4-5 days would be great for
> testing my knowledge of perl and quantify my progress.

Like I said to Matthias, Perl comes with an extensive set of manpages
which consist of tutorials and reference manuals.  ‘perlintro(1)’ is a
good entry point.  The “Learning Perl” book by Tom Phoenix and Randal
Schwartz is a nice introduction to Perl.

You will need to get familiar with perl references which is a somewhat
advance topic in order to build recursive structure for the AST.

To learn Perl I think it is important to have an interactive environment
‘perl -d -e ''’ is useful for that.

> 2) How to go about understanding the Automake code .

The first step is to compile it from the Git repository and report
unclear points.  I encourage you to get familiar with Automake from a
user perspective by creating build definitions for some dummy C programs
and libraries by following the Automake manual which is nicely written.

> 3) Any other task required to be completed during the community bonding 
> period.

I think, it is important that you get more familiar with Git usage and
good practices before the coding period.  There is a lot of resources
online and particularly a great book freely available:

  https://git-scm.com/book/en/v2

> As discussed in the proposal that I will be having my exams from 8th
> to 15th May, so I will try to complete the work before that time.

No problem.

If you have any question or difficulty in your discovery, you can ask on
the #autotools IRC channel on Freenode or directly to me (my pseudo is
‘mthl’).  I am not sure about your actual timezone (mine is UTC+2) but
if you are from India don't expect me to available too soon in the
morning.  :-)

HTH,

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Proposal accepted

[Mathieu Lirzin]

Hello Matthias,

Matthias Paulmier <matthias.paulm...@etu.u-bordeaux.fr> writes:

> I am very glad to announce that my proposal has been accepted ! I will
> be working this summer on modularizing Automake and improving its test
> suite.

Congrats.

> The community bonding period starts today until May the 14th. I will be
> a bit busy this week with my final exams (I failed to mention it in my
> proposals since I didn't realize those two things would overlap). My
> exams end on Friday.

No problem.

> As explained in my proposal, I will dedicate this period to familiarize
> myself with the Perl programming language as well as Automake's code. If
> anyone has any tips on how to setup my environment for it I will gladly
> take them :) (I'm using Debian GNU/Linux testing and Emacs as my
> editor). I am also looking for good resources on Perl.

It depends on your preference but basically Emacs has 2 major modes for Perl:

  - perl-mode
  - cperl-mode

‘perl-mode’ is the default but you can use ‘cperl-mode’ by adding the
following to your “.emacs”:

   (defalias 'perl-mode 'cperl-mode)

I found it nice to have an interactive interpreter when programming with
perl.  In emacs you can run ‘M-x perldb  perl -d -e ''’ for that.

One important point and not solved yet will be to use tags to navigate
to the definition of a particular subroutine easily.  I will take a look
if the ‘make tags’ result can be fixed.  For now you can use ‘M-x
rgrep‘.

In term of documentation Perl comes with an extensive set of manpages
which consist of tutorials and reference manuals.  In Emacs they can
conveniently be accessed with ‘M-x man  perl’.  ‘perlintro(1)’ is a
good entry point.  You can take a look at the “Learning Perl” book by
Tom Phoenix and Randal Schwartz too.

In order to discover Automake, the best you can do at the beginning is
to compile it (from Git) and report unclear points.  It will be
important to broadly understand Automake from a user perspective before
the coding period, so you can alternate your perl discovery with some
experimentation with Automake by following Automake info manual.

If you have any questions or difficulty in your discovery, you can ask
on the #autotools IRC channel on Freenode or directly to me (my pseudo
is ‘mthl’).

HTH,

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Mathieu Lirzin]

Hello Peter,

Peter Johansson <troj...@gmail.com> writes:

> On 4/22/2018 1:13 AM, Mathieu Lirzin 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:
>>>
>>> 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 in two attempts to
>>> make a library in parallel (suppose that we have:
>>>
>>> foo_LDADD = libfoo.la
>>> lib_LTLIBRARIES = libfoo.la
>>>
>>> ). This can fail, and in any case is wasteful.
>> Have you identified the reason why this can fail?  because
>
> One problem is that the rule for foo.1 can be triggered before
> foo.$(EXEEXT) exists and the rule needs foo.$(EXEEXT) or help2man will
> fail. In a -j1 build this is never a problem as binaries are built
> before man pages.

with the ‘$(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)’ recipe line, normally
this ensures that the ‘foo$(EXEEXT)’ is built at least once.  My
question was about understanding why building a program/library twice
may end up in a failure in a parallel context.

The answer from Reuben was that since compilation is not thead safe when
for example deleting shared temporary files, then concurrent processes
might impact each other.

> When the 'missing' script changed behaviour in Automake 1.13 (and
> became useless imvho), we changed the rule in one project so foo.1
> depended on foo.$(EXEEXT) but not if we are 1) building from a tarball
> and 2) foo.$(EXEEXT) exists.
>
> http://dev.thep.lu.se/svndigest/browser/trunk/man/Makefile.am

This is an alternative solution which is used by GNU Hello too.  I
remember some people not being fond of this approach because of its
AM_MAINTAINER_MODE spirit [1].

[1] 
https://www.gnu.org/software/automake/manual/html_node/maintainer_002dmode.html

Thanks for your feedback.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Mathieu Lirzin]

Reuben Thomas <r...@sc3d.org> writes:

> On 21 April 2018 at 16:13, Mathieu Lirzin <m...@gnu.org> wrote:
>
>  Reuben Thomas <r...@sc3d.org> 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
>  > $(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)
>  > help2man --output=foo.1 ./foo$(EXEEXT)
>  >
>  > The problem is that with make -j this can result in two attempts to
>  > make a library in parallel (suppose that we have:
>  >
>  > foo_LDADD = libfoo.la
>  > lib_LTLIBRARIES = libfoo.la
>  >
>  > ). This can fail, and in any case is wasteful.
>
>  Have you identified the reason why this can fail? because 
>
> ​Because two independent parallel invocations of make ​can end up trying
> to build the library (which is wasteful anyway) and some needed file
> can be deleted by one invocation when the other is trying to use it to
> link the library.

Makes sense.

>  This is not ideal since this result in making ‘help2man’ (and ‘perl’
>  transitively) a build dependency for tarball builders.
>
> ​I'm increasingly of the view this is not a problem. Perl is
> increasingly reasonable as a build dep (it seems to be in most base
> systems now), and help2man is small.

In term of convenience for end users, I agree this is often a harmless
issue.  However having been involved in GNU Guix for awhile I think it
is important to avoid accidental dependencies to improve the simplicity
of the bootstrapping process of our systems [1][2].

>  $(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 one thing I don't understand: why is "-" needed at the start
> (i.e. why do we need to ignore failure of this command?).

I don't recall exactly the reason Guix added it, I guess it was to allow
the build to "succeed" even if the man pages generation failed since
that doesn't impact the software to run.  However I am not sure if it's
a good idea.

> Combining the above with what I originally posted, I get:
>
> beetle.1: tbl_opts.h beetle$(EXEEXT)
> ## Exit gracefully if beetle.1 is not writeable, such as during distcheck!
> @if ( touch $@.w && rm -f $@.w; ) >/dev/null 2>&1; then \

IIUC this case silently ignores when the ‘beetle.1’ is not distributed,
which doesn't seem desirable for ‘make distcheck’, no?
 
> case '$?' in \
> *tbl_opts.h*) $(AM_V_P) && set -x || echo " HELP2MAN $@"; \
> $(top_srcdir)/build-aux/missing --run $(HELP2MAN) --no-info \
> --name="Forth virtual machine" \
> --output=$@ ./beetle$(EXEEXT);; \
> *) : ;; \
> esac; \
> fi

[1] https://www.gnu.org/software/guix/manual/html_node/Bootstrapping.html
[2] http://bootstrappable.org/

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Mathieu Lirzin]

Hello Reuben,

Reuben Thomas <r...@sc3d.org> 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
> $(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)
> help2man --output=foo.1 ./foo$(EXEEXT)
>
> The problem is that with make -j this can result in two attempts to
> make a library in parallel (suppose that we have:
>
> foo_LDADD = libfoo.la
> lib_LTLIBRARIES = libfoo.la
>
> ). This can fail, and in any case is wasteful.

Have you identified the reason why this can fail?  because 

> I'm using automake 1.15. I can't see anything since then that fixes this 
> problem.

Yes, this problem is likely to still be present in 1.16.1.

> The best workaround I could come up with was to revert the dependency to​
>
> ​ foo.1: foo$(EXEEXT)
>
> and then set distcleancheck_listfiles appropriately. Obviously, since
> this could hide other problems in the build system, it's not ideal.

This is not ideal since this result in making ‘help2man’ (and ‘perl’
transitively) a build dependency for tarball builders.

> Am I missing a better solution? If so, it should be added to the
> manual. If not, this problem should probably be documented. I'm
> finding that parallel make is becoming a must-have rather than a nice
> boost, given the proliferation of slow multi-core machines (for
> example: -j makes it feasible to hack on my phone; without it, builds
> are painfully slow).

I agree that it is important to provide a solution that support parallel
builds.  I remember that the issue has been adressed by Guix with
something like this (untested):

--8<---cut here---start->8---
$(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;
--8<---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

Re: Can't build automake-1.16: Can't locate Automake/Config.pm in @INC

[Mathieu Lirzin]

Hello,

"George Gaarder" <ggaar...@foxmail.com> writes:

> Very sorry. The previous mail has some typesetting issues. So I sent
> it again. Terminal session goes here: $ make GEN bin/automake GEN
> bin/aclocal GEN bin/aclocal-1.16 GEN bin/automake-1.16 GEN
> t/ax/shell-no-trail-bslash GEN t/ax/cc-no-c-o GEN runtest GEN
> doc/aclocal.1 GEN doc/automake.1 GEN lib/Automake/Config.pm GEN
> doc/aclocal-1.16.1 GEN doc/automake-1.16.1 help2man: can't get
> `--help' info from automake-1.16 Try `--no-discard-stderr' if option
> outputs to stderr make: *** [doc/automake-1.16.1] Error 255 $
> bin/automake-1.16 Can't locate Automake/Config.pm in @INC (you may
> need to install the Automake::Config module) (@INC contains:
> /usr/local/share/automake-1.16 /usr/local/lib64/perl5
> /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
> /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
> bin/automake-1.16 line 47. BEGIN failed--compilation aborted at
> bin/automake-1.16 line 47.

Can you send the output of ‘./pre-inst-env automake --help’ and attach
the ‘config.log’ file of this build?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[GSoC] Seeking mentors

[Mathieu Lirzin]

Hello,

I have requested 2 slots for Google Summer of Code this year.

While it is possible for me to mentor both projects, Giuseppe Scrivano
has pointed me that it would be preferrable to have separate mentors for
each project.

The task consists in discussing with the students about their work and
providing some help/guidance.  The ideal mentor would have some
experience with Automake codebase, a basic knowledge of Perl, and have
some time (~4 hours/week) to spend on it.

So I would like to know if someone is willing to volunteer for that
role.  In any case, I am willing to help with the mentoring task.  If
you are interested please step-up!

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Fixes for Windows

[Mathieu Lirzin]

Hello Olly,

Sorry for the delay.

Olly Betts <o...@survex.com> writes:

> On 2018-01-24, Olly Betts <o...@survex.com> wrote:
>> I found I needed the two attached patches to build Xapian
>> (https://xapian.org) on Windows.
>>
>> The second patch is only needed when using libtool, but should
>> be harmless when not.
>
> It's now been two months since I sent these, and there's been no
> response at all and it doesn't look like they've been applied, despite
> two new automake releases being made since.  
>
> Is this list no longer the appropriate place to send patches?
> If not, then README needs updating.

This is the appropriate place for sending patches.

The main reason that your patch didn't get reviewed yet is that I am
incompetent for issues related to Cygwin/MinGW/MSYS, so I was waiting
for someone to jump in and then forgot about it.  :-)

> From 91fb05a87c7a9eb784a84b14b74313740189c402 Mon Sep 17 00:00:00 2001
> From: Olly Betts <o...@survex.com>
> Date: Wed, 24 Jan 2018 13:38:03 +1300
> Subject: [PATCH 1/2] Use cygpath for filename conversion on MSYS
>
> * lib/ar-lib(func_file_conv): Set file_conv=cygwin for MSYS.
> * lib/compile(func_file_conv): Likewise.
> ---

This one seems harmless.

> From 010511fe83a765238e0cb050621beee5a00fce69 Mon Sep 17 00:00:00 2001
> From: Olly Betts <o...@survex.com>
> Date: Wed, 24 Jan 2018 13:43:42 +1300
> Subject: [PATCH 2/2] lib/compile: Handle libtool .lo files
>
> * lib/compile(func_cl_wrapper): Add *.lo to list of files to handle
> as object files.
> ---
>  lib/compile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/compile b/lib/compile
> index 7851f7c4..e2931cf9 100755
> --- a/lib/compile
> +++ b/lib/compile
> @@ -143,7 +143,7 @@ func_cl_wrapper ()
> # configure might choose to run compile as 'compile cc -o foo foo.c'.
> eat=1
> case $2 in
> - *.o | *.[oO][bB][jJ])
> + *.o | *.lo | *.[oO][bB][jJ])
> func_file_conv "$2"
> set x "$@" -Fo"$file"
> shift

Unless I am mistaken, this issue is more general and applies every time
‘compile’ is used for ‘.lo’ files.  I think a test revealing the issue
can be added in the test suite. You can either modify an existing one
from the ‘t/compile*.sh’ files if the issue is closely related to an
already tested one, or if that is not the case you can add a new test
script.

Can you add a rationale in the commit message before the ChangeLog part
too?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSOC] Proposal for "Modularize Automake to improve the test-suite performance"

[Mathieu Lirzin]

Hello,

Matthias Paulmier <matthias.paulm...@etu.u-bordeaux.fr> writes:

> I am candidating for the project "Modularize Automake to improve the
> test-suite performance"
>
> As you may have noticed, this is my second proposal for the GSoC to the
> Automake project. You may have also noticed that 2 other persons are
> interested in this other project. This is why I have decided, after
> speaking with Mathieu Lirzin, that it would be a wise idea to candidate
> to other projects or project ideas. The goal of the summer of code is
> not to have a race with other candidates. As Mathieu told me, there may
> be multiple students working for Automake under his mentorship.

To be precise I will mentor at most 2 students. :-)

> You will find my proposal for this subject here :
> matthias.paulmier.emi.u-bordeaux.fr/proposal_am_2.pdf. Please give me
> feedbacks on this proposal. I am conscious it is bit lackey as I have
> thought more about the previous one (for example I don't know what to
> add to the deliverables).

This project is highly iterative, meaning that you will have to define
the modules you will be writing based on what you analyse while
refactoring.  So for the deliverables a "set" of modules is fine.

The idea is that the modules should be written so that they can be
easily testable (without requiring convoluted mocks for
example). Ideally you can define the qualities (like low coupling) that
the written modules should have.

The most important part in this proposal should be the description of
the various testing strategies that you intend to use and the generic
software architectures that could help with the modularity goal.  If you
are not familiar with either Testing or Architecture concepts for
example with terms like blackbox/whitebox testing, you should consider
studying those concepts in the community bounding phase.

Regarding the plan I think the beginning should contain at least the
following two things:

* A rewrite of the few existing unit tests with Test::More to get
  familiar with the framework.

* An analysis phase with the production of a small report containing
  some informal UML diagrams representing the current architecture of
  'automake'.

> I have been advised to look at other projects but as I said, I didn't
> find much interest in other projects either because of technical or
> philosophical aspects. I will however take a second look at other
> projects from GNU as there has been new idea submissions since I
> candidated here and if I find interesting projects I will likely make a
> proposal tonight (CET) or tomorrow and keep you informed.

IMHO with 2 proposals you should be fine in particular with this
"Modularize" project that doesn't get much traction.  But feel free to
look around. :-)

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [gnu-soc] Automake - Summer of Code - Has any student taken on the "Parse Makefile.am using an Abstract Syntax Tree" project?

[Mathieu Lirzin]

Hello Khuong,

luukh <lu...@oregonstate.edu> writes:

> I'm a Junior student in Computer Science at Oregon State University,
> US.
>
> This afternoon, I just heard about this project from my Compiler class
> instructor which I just finished, so I'm totally aware that I'm very
> late to the party.

Just out of curiosity who is your instructor? :-)

> I'm interested in the project "Parse Makefile.am using an Abstract
> Syntax Tree". I have 2 questions:
>
> 1 Has any student has proposed or taken on this project yet?

Yes there is already 2 candidates, but project attribution will made
after the deadline which is set to March, 27.

> 2 If there has been, should I or am I allowed to propose/apply to this
> project?

Yes you can still apply.

> Once I receive a "yes" from you, I will start writing the proposal
> immediately and finished it in a day for you to revise.
>
> A brief related technical background about me: 
>
> * Since I have just finished a course in Compiler at my university, I
> have a basic understanding of Compiler phase. I have implemented a
> parser for a subset of syntax of Python that generates an Abstract
> Syntax tree from the source file as well as using GraphViz to
> visualize it. Here is the link to this project on Github.
>
> * I'm also in progress of completing the rest of the project, which is
> generating LLVM IR representing the Python source program, then run
> some optimizations on that IR before using it to generate object code
> for a target machine.
>
> * I have skills in Data Structure, Algorithm Analysis, intermediate
> level in C/C++, and a basic understanding of Unix/Linux operating
> system.
>
> * I don't have experience in Perl but I'm can pick it up quickly on
> the project.
>
> * Here is my Github profile.

Looks interesting, Make sure to include those information in your
proposal draft.  You can send this draft only to <automake@gnu.org> and
drop <summer-of-c...@gnu.org> from the Cc.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: GSOC GNU Automake project

[Mathieu Lirzin]

Vishal Gupta <vishalgupta7...@gmail.com> writes:

> I have uploaded the draft proposal on the GSoC website.
> Here is the link for the uploaded document. 
> (https://docs.google.com/document/d/1M740xtKJ6OiWtIX-iYlS8U09FaRfU2SJIQ4tUGjmhbo/edit?usp=sharing)
>
> Please check my draft and suggest improvement.

This is a good first draft.

A few comments/suggestions:

- You can precise what University curriculum you are currently
  following.

- You can precise what are your personnal motivation for participating
  in the GSoC in general and candidating for this specific project.

- I would be interested in knowing if you have previous experiences with
  any Free Software project even if this is minor contributions.

- Regarding the COOL compiler, some pointers would be welcome.

- Regarding the RDBMS project is that a assignment or a preexisiting
  project you got involved in?  It would be interesting if you could
  precise the specific parts you have been working on and what was
  already done.  Is there any pointer to check what the project is
  about?

- Additionally You can tell us about your intuition regarding what kind
  of nodes the AST would probably contain.

Feel free to continue expanding on your plan by precising the functional
and non-functional requirements and telling us how you imagine you would
specifically tackle those.

If you have questions regarding my comments or about more general one
regarding the project itself, don't hesitate.

Thanks for your proposal.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> writes:

>> My draft is online on the GSoC website since it was open on Monday. I
>> don't know if you have access to that.
>
> Yes I have access to it.  I will send my future comments via this
> website.

I was under the wrong impression that using this interface was the way
to communicate with applicants, but this seems not to be the case so I
will continue to send my comments to this thread.

Few additional comments:

- I agree with your suggestion of providing numbers regarding the
  performance impact of using an AST.

- In the "qualification" part, you can include all the details you
  provided regarding your school project.

Feel free to continue expanding on the technical details and request
feedback until the deadline.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[Mathieu Lirzin]

Matthias Paulmier <matthias.paulm...@etu.u-bordeaux.fr> writes:

> Mathieu Lirzin <m...@gnu.org> writes:
>
>> Matthias Paulmier <matthias.paulm...@etu.u-bordeaux.fr> writes:
>>
>>> I put up the first draft for my proposal here :
>>> .
>>
>> - Regarding the example script deliverable, I think you can precise that
>>   a set of examples that can be manually tested will be provided.  If it
>>   helps you and fit your workflow (for example if you want to do TDD or
>>   similar), you can add some automated unit tests however this is not a
>>   requirement.
>
> That has been added. As for TDD, I'm not an expert on that but some
> tests may be provided during the summer as part of the test suite under
> the t/ directory.

Yes indeed the ‘t/’ directory contains validation tests, and ‘t/pm’
directory contains unit tests.

If you wan't to write unit tests I encourage you to look at the classic
‘Test::More’ framework instead of following what is done in ‘t/pm’ which
is a bit too barebone in my opinion.

For validation tests they should be easy automatable with basic shell
scripts calling the example script and checking the output.

>>> The communication part still needs to be discussed. As for the plan tell me 
>>> what
>>> you think.
>>
>> Regarding the communication.  For the weekly status update and
>> discussion, if that's OK with you I would rather have a VOIP one on one
>> conversation (via Ring or Jitsi) when possible and use email as a
>> fallback or complement.  Regarding the instantaneous communication IRC
>> is convenient for me.
>
> Sounds good to me. I put Jitsi in the proposal since it doesn't need
> registration and I don't have a Ring ID ATM. But I don't have a real
> preference.

Great.

> My draft is online on the GSoC website since it was open on Monday. I
> don't know if you have access to that.

Yes I have access to it.  I will send my future comments via this
website.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[Mathieu Lirzin]

Hello Matthias,

Matthias Paulmier <matthias.paulm...@etu.u-bordeaux.fr> writes:

> I put up the first draft for my proposal here :
> .

I think this is a good first draft.

A few comments:

- For the “Project” and “Plan” parts, feel free to expand on the
  functional and non-functional requirements, based on previous
  discussion (for example the fact that the AST will probably have a
  coarse grain) and from your personal intuition.  It doesn't matter if
  your intuition doesn't match with what I have in mind, it will just be
  a good occasion to discuss the project in more details.

- Regarding the example script deliverable, I think you can precise that
  a set of examples that can be manually tested will be provided.  If it
  helps you and fit your workflow (for example if you want to do TDD or
  similar), you can add some automated unit tests however this is not a
  requirement.

- For the documentation, this doesn't have a high priority.  I will be
  happy with just some basic docstrings specifying the functional
  contract of subroutines.

> The communication part still needs to be discussed. As for the plan tell me 
> what
> you think. 

Regarding the communication.  For the weekly status update and
discussion, if that's OK with you I would rather have a VOIP one on one
conversation (via Ring or Jitsi) when possible and use email as a
fallback or complement.  Regarding the instantaneous communication IRC
is convenient for me.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: GSOC GNU Automake project

[Mathieu Lirzin]

Hello Vishal,

Vishal Gupta <vishalgupta7...@gmail.com> writes:

> I am interested in working on the project to Parse Makefile.am using an
> Abstract Syntax Tree. Some queries related to the project are :-
> 1) In which language is the lexer and parser expected to be written and
> using which tools.

It should be written directly in Perl like the rest of Automake.

> 2) Where to put my draft proposal for review so that it can be improved.

You can host it on the Web as HTML or PDF, or simply send it as plain
text by Email to this Mailing List.

There is another student applying for this projet.  You can take a look
at the mailing-list archives [1] for past discussion regarding the
subject.

Thanks for your interest.

[1] https://lists.gnu.org/archive/html/automake/2018-03/threads.html

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH] bin: Rely only on the shebang line

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> writes:

> Previously ‘automake’ and ‘aclocal’ were handling the case of being
> interpreted as a Shell script by using a hack leveraging the fact that
> Shell and Perl has a compatible syntax intersection allowing those
> scripts to launch ‘perl’ from the shell.
>
> * bin/aclocal.in: Remove cryptic launching hack.
> * bin/automake.in: Likewise.
> ---
>  bin/aclocal.in  | 8 +---
>  bin/automake.in | 7 +--
>  2 files changed, 2 insertions(+), 13 deletions(-)

Applied as commit 51823f144c513007d8c05f3c6c88732e91bd13fd.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH] install-sh: avoid (low risk) race in /tmp

[Mathieu Lirzin]

Hello,

Sorry for the long delay.

Pavel Raiskup <prais...@redhat.com> writes:

> Ensure that nobody can cross privilege boundaries by pre-creating
> symlink on '$tmpdir' path.
>
> Just testing 'mkdir -p' by creating '/tmp/ins$RANDOM-$$/d' is not
> safe because '/tmp' directory is usually world-writeable and
> '/tmp/ins$RANDOM-$$' content could be pretty easily guessed by
> attacker (at least for shells where $RANDOM is not supported).
> So, as the first step, create the '/tmp/ins$RANDOM-$$' without -p.
> This step would fail early if somebody wanted catch us.
>
> Note that systems that implement (and have enabled)
> fs.protected_symlinks kernel feature are not affected even without
> this commit.
>
> References:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760455
> https://bugzilla.redhat.com/show_bug.cgi?id=1140725
>
> * lib/install-sh: Implement safer 'mkdir -p' test by running
> '$mkdirprog $mkdir_mode "$tmpdir"' first.
> (scriptversion): Bump.
> ---
>  lib/install-sh | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)

Applied in commit 968bf9f66e3966d1975295b97539876518ebd2a0.

Thank you for the patch.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

GNU Automake 1.16.1 released

[Mathieu Lirzin]

We are pleased to announce the GNU Automake 1.16.1 maintenance release.

This release follows 1.16 which was made 2 weeks ago.

See below for the detailed list of changes since the
previous version, as summarized by the NEWS file.

Download here:

  https://ftp.gnu.org/gnu/automake/automake-1.16.1.tar.gz
  https://ftp.gnu.org/gnu/automake/automake-1.16.1.tar.xz

Please report bugs and problems to ,
and send general comments and feedback to .

Thanks to everyone who has reported problems, contributed
patches, and helped testing Automake!

-*-*-*-

* WARNING: Future backward-incompatibilities!

  - Makefile recipes generated by Automake 2.0 will expect to use an
'rm' program that doesn't complain when called without any non-option
argument if the '-f' option is given (so that commands like "rm -f"
and "rm -rf" will act as a no-op, instead of raising usage errors).
This behavior of 'rm' is very widespread in the wild, and it will be
required in the next POSIX version:

  

Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
that the default 'rm' program in PATH satisfies this requirement,
aborting the configure process if this is not the case.  For the
moment, it's still possible to force the configuration process to
succeed even with a broken 'rm', that that will no longer be the case
for Automake 2.0.

  - Automake 2.0 will require Autoconf 2.70 or later (which is still
unreleased at the moment of writing, but is planned to be released
before Automake 2.0 is).

  - Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file.  You are advised to start using the
recommended name 'configure.ac' instead, ASAP.

  - The ACLOCAL_AMFLAGS special make variable will be fully deprecated in
Automake 2.0: it will raise warnings in the "obsolete" category (but
still no hard error of course, for compatibilities with the many, many
packages that still relies on that variable).  You are advised to
start relying on the new Automake support for AC_CONFIG_MACRO_DIRS
instead (which was introduced in Automake 1.13).

  - Automake 2.0 will remove support for automatic dependency tracking
with the SGI C/C++ compilers on IRIX.  The SGI depmode has been
reported broken "in the wild" already, and we don't think investing
time in debugging and fixing is worthwhile, especially considering
that SGI has last updated those compilers in 2006, and retired
support for them in December 2013:


  - Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
(support for them was offered by relying on the DJGPP project).
Note however that both Cygwin and MSYS/MinGW on modern Windows
versions will continue to be fully supported.

  - Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 2.0.  There still is no
certainty about this though: we'd first like to wait and see
whether future Autoconf versions will be enhanced to guarantee
that such a shell is always found and provided by the checks in
./configure.

  - Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros.  For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-2.0/vala.m4').



New in 1.16.1:

* Bugs fixed:

  - 'install-sh' now ensures that nobody can cross privilege boundaries by
pre-creating symlink on the directory inside "/tmp".

  - 'automake' does not depend on the 'none' subroutine of the List::Util
module anymore to support older Perl version. (automake bug#30631)

  - A regression in AM_PYTHON_PATH causing the rejection of non literal
minimum version parameter hasn't been fixed. (automake bug#30616)




signature.asc
Description: PGP signature

bug#30612: [automake-1.16] make check fails on Solaris 11.3 x86

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> 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 interested.

Here are the logs on my system without the above commit



test-suite.log
Description: Binary data

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30612: [automake-1.16] make check fails on Solaris 11.3 x86

[Mathieu Lirzin]

Hello,

Kiyoshi KANAZAWA <yoi_no_myou...@yahoo.co.jp> writes:

> Trying to install automake-1.16 on Solaris 11.3 x86.
> make check fails with
>
> FAIL: t/lex-clean-cxx.sh
> FAIL: t/lex-depend-cxx.sh
>
>
> It seems to be caused by declaration of yylex ().
> lex-clean-cxx.log & lex-depend-cxx.log are attached.
>
>
> Tested with gcc 7.3.0, 
>
> % ./configure
> % make
> % make check
>

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 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

bug#30631: Automake 1.6 fails to build with perl 5.18.2

[Mathieu Lirzin]

Torsten Seemann <tseem...@unimelb.edu.au> 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

bug#28160: Support newer version of python

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> 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 <m...@gnu.org>
> Date: Sat, 3 Mar 2018 12:01:13 +0100
> Subject: [PATCH] python: Support future python version up to 3.9
>
> This change fixes automake bug#28160.
>
> Since AM_PYTHON_PATH macro takes no maximum version argument, there is
> no need to generate _AM_PYTHON_INTERPRETER_LIST dynamically, like what
> was previously done by the reverted commit
> 1d60fb72168e62d33fe433380af621de64e22f23.  We could rely on M4 to
> generate this list statically however this is likely to be a complex
> solution that would not improve maintainability.
>
> * m4/python.m4 (_AM_PYTHON_INTERPRETER_LIST): Add 'python3.7',
> 'python3.8', and 'python3.9'.
> ---

Pushed as commit 9385c161707c6d2295d610eef81fe4d1a44b44de.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[Mathieu Lirzin]

Hello Matthias,

Matthias Paulmier <matthias.paulm...@etu.u-bordeaux.fr> writes:

> I'm a french CS student at the University of Bordeaux. I'm currently 
> following a
> masters degree course specialized in network communications and 
> administration.
> I've been interested in free software for a couple of years now and have been
> willing to help a project for some time, but never found one I could help 
> with a
> significant contribution before that.
>
> I have decided to candidate for the project "Parse Makefile.am using an 
> Abstract
> Syntax Tree".

Your proposal is very welcome.  Google Summer of Code is a good
opportunity to start contributing to Free Software.

> The reason I'm choosing this subject over the other one is that I already have
> good knowledge about ASTs. I have worked on a small programming language as an
> assignment (project here :
> <https://services.emi.u-bordeaux.fr/projet/viewvc/compilfinal/> but it is very
> poorly written). It is a very basic interpreter for a trimmed Pascal 
> programming
> language written in C with Flex and Bison. On this project I've worked on the
> syntax and semantic analysis as well the lexer (which is not a big deal with
> Flex).
>
> I've already met with Mathieu Lirzin to talk about the project so I have a
> general idea of what is expected of this GSoC. From my understanding, both
> proposed subjects' goal is to go towards Automake's eventual modularization. 
> The
> benefits of generating this AST from a Makefile.am file would be to separate 
> the
> different code generation phases, improve the test suite by testing each phase
> separately and probably others that it can't think about now.
>
> My knowledge in Perl may be my weak point for this project as I only know a 
> bit
> of the syntax. But I am familiar with other programming languages, 
> principally C
> and Python.

The background you have of this compilation course would be helpful for
this project.  IMO The lack of knowledge of Perl is not a big deal,
however it means you will have to acquire a basic knowledge of Perl
during the "Community Bonding" period.

> If you have any suggestions on documents I can read or software I can check to
> prepare for this project I'll be glad to check them. I know texinfo is written
> in Perl and generates an AST so I'll check that.

Yes looking at Texinfo will be interesting for that.

I think you should start thinking on a roadmap with the milestones and
deadlines for your formal application.  The deliverables that are
expected for this project are on one hand a Perl library capable of
parsing 'Makefile.am' files, of injecting rudimentary predefined
compilation rules based on the semantic analysis, and of dumping the
resulting 'Makefile.in'.  A example script using that library should be
developped to easily be able to check the progress of the parsing and
code generation work.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[Mathieu Lirzin]

NightStrike <nightstr...@gmail.com> writes:

> On Mar 7, 2018 16:05, "Mathieu Lirzin" <m...@gnu.org> wrote:
>
>  John Calcote <john.calc...@gmail.com> writes:
>
>  > A Makefile.am file is really just a Makefile with embellishments. It seems
>  > like your ast would have to incorporate most of make’s syntax to work
>  > correctly.
>  >
>  > The reason Perl was chosen to begin with is because of its great text
>  > processing capabilities as, ultimately, all automake really does is copy
>  > the file directly to the output Makefile.in file, filtering out automake
>  > stuff along the way and injecting make snippets generated from the automake
>  > constructs.
>  >
>  > This may not appear obvious at first because many simpler Makefile.am files
>  > contain only automake stuff. But anything found in the Makefile.am file
>  > that automake doesn’t recognize is assumed to be proper make script and
>  > copied directly to the output file.
>  >
>  > I suggest making your ast handle non automake chunks as a specific token
>  > type designed to be passed through without modifications.
>
>  I agree that using a coarse grained AST is a good first approach.
>  Exploration and evaluation of a finer grained approach later during this
>  GSoC could be interesting too.
>
>  Thanks for your input.
>
> What problem does the AST solve? 

The main one I see is the potential modularity and performant
testability it brings.  Checking some properties in an in-memory tree
data structure instead of reading a file has generally better
performance.  While this performance gain is not important in an
practical interactive usage of 'automake', the benefit will be
significative for the test-suite runtime assuming that most functional
tests are rewritten as unit tests.

Using an AST is not the only possible approach to achieve this goal of
having an in-memory data structure for the tests.  However the AST
approach is generally considered a better design for syntax/semantic
analysis than having a couple of streams of character combined with a
set of global variables.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[Mathieu Lirzin]

John Calcote <john.calc...@gmail.com> writes:

> Hi Matthias,
>
> If you have any suggestions on documents I can read or software I can check
>> to
>> prepare for this project I'll be glad to check them. I know texinfo is
>> written
>> in Perl and generates an AST so I'll check that.
>>
>
> A Makefile.am file is really just a Makefile with embellishments. It seems
> like your ast would have to incorporate most of make’s syntax to work
> correctly.
>
> The reason Perl was chosen to begin with is because of its great text
> processing capabilities as, ultimately, all automake really does is copy
> the file directly to the output Makefile.in file, filtering out automake
> stuff along the way and injecting make snippets generated from the automake
> constructs.
>
> This may not appear obvious at first because many simpler Makefile.am files
> contain only automake stuff. But anything found in the Makefile.am file
> that automake doesn’t recognize is assumed to be proper make script and
> copied directly to the output file.
>
> I suggest making your ast handle non automake chunks as a specific token
> type designed to be passed through without modifications.

I agree that using a coarse grained AST is a good first approach.
Exploration and evaluation of a finer grained approach later during this
GSoC could be interesting too.

Thanks for your input.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: automake-1.16: aclocal is unable to process AM_PATH_PYTHON with variable as value

[Mathieu Lirzin]

Adam Mercer <ramer...@gmail.com> writes:

> On Tue, Feb 27, 2018 at 9:07 PM, Adam Mercer <ramer...@gmail.com> 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): 
>>>> (0r36:PYTHON_+1) != (0*4)
>>>> autom4te-2.69: /usr/bin/m4 failed with exit status: 1
>>>> aclocal-1.16: error: echo failed with exit status: 1
>
> Looks like the reversion of 1d60fb72168e62d33fe433380af621de64e22f23
> has fixed this problem and I can build my projects again.
>
> Is there an ETA for a point release containing this fix?

I hope to release it next weekend.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30631: Automake 1.6 fails to build with perl 5.18.2

[Mathieu Lirzin]

Hello,

Torsten Seemann <tseem...@unimelb.edu.au> writes:

> The problem is that automake 1.16 is importing the function "none"
> from perl List::Util module.  Unfortunately, "none" was only added to
> that module in v 1.33 and Perl 5.18 has an older version.  This only
> occurs in "bin/automake.in"
>
> The simplest patch is for the authors to change 
>
> use List::Util 'none'
> =>
> use List::Util 'any'
>
> And replace their use of the function (only one case) as so:
>
> && none { 
> =>
> && ! any {

According to [1] both 'none' and 'any' were added in List::Util 1.33.

There is indeed a portability bug on the Automake side since
'configure.ac' claims to be compatible with Perl 5.6 and Looking at the
perl distributions [2] it seems that 5.6.2 does not have List::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 17 00:00:00 2001
From: Mathieu Lirzin <m...@gnu.org>
Date: Sat, 3 Mar 2018 23:50:10 +0100
Subject: [PATCH] automake: Don't rely on List::Util to provide 'none'

This change fixes automake bug#30631.

This removes the use of List::Util which is not supported by Perl 5.6,
by reimplementing the 'none' subroutine.

* lib/Automake/General.pm (none): New subroutine.
* bin/automake.in (handle_single_transform): Use it.
* t/pm/General.pl: New test.
* t/list-of-tests.mk (perl_TESTS): Add it.
---
 bin/automake.in |  3 +--
 lib/Automake/General.pm | 20 +++-
 t/list-of-tests.mk  |  1 +
 t/pm/General.pl | 27 +++
 4 files changed, 48 insertions(+), 3 deletions(-)
 create mode 100644 t/pm/General.pl

diff --git a/bin/automake.in b/bin/automake.in
index 16fb45182..a52a48951 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -73,7 +73,6 @@ use Automake::Wrap 'makefile_wrap';
 use Automake::Language;
 use File::Basename;
 use File::Spec;
-use List::Util 'none';
 use Carp;
 
 ## --- ##
@@ -1793,7 +1792,7 @@ sub handle_single_transform
 my $dname = $derived;
 if ($directory ne ''
 && option 'subdir-objects'
-&& none { $dname =~ /$_$/ } @dup_shortnames)
+&& none { $dname =~ /$_[0]$/ } @dup_shortnames)
   {
 # At this point, we don't clear information about what
 # parts of $derived are truly file name components.  We can
diff --git a/lib/Automake/General.pm b/lib/Automake/General.pm
index 32f5c8db7..aa2de38b8 100644
--- a/lib/Automake/General.pm
+++ b/lib/Automake/General.pm
@@ -23,7 +23,7 @@ use File::Basename;
 use vars qw (@ISA @EXPORT);
 
 @ISA = qw (Exporter);
-@EXPORT = qw ( $me);
+@EXPORT = qw (  $me);
 
 # Variable we share with the main package.  Be sure to have a single
 # copy of them: using 'my' together with multiple inclusion of this
@@ -66,5 +66,23 @@ sub uniq (@)
return wantarray ? @res : "@res";
 }
 
+# $RES
+# none (, @LIST)
+# 
+# Return 1 when no element in LIST satisfies predicate PRED otherwise 0.
+sub none (&@)
+{
+  my ($pred, @list) = @_;
+  my $res = 1;
+  foreach my $item (@list)
+{
+  if ($pred->($item))
+{
+  $res = 0;
+  last;
+}
+}
+  return $res;
+}
 
 1; # for require
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 271bfb573..84dd29af0 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -54,6 +54,7 @@ t/pm/DisjCon2.pl \
 t/pm/DisjCon3.pl \
 t/pm/DisjConditions.pl \
 t/pm/DisjConditions-t.pl \
+t/pm/General.pl \
 t/pm/Version.pl \
 t/pm/Version2.pl \
 t/pm/Version3.pl \
diff --git a/t/pm/General.pl b/t/pm/General.pl
new file mode 100644
index 0..0caefe7cf
--- /dev/null
+++ b/t/pm/General.pl
@@ -0,0 +1,27 @@
+# Copyright (C) 2018 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+use Automake::General;
+
+my $failed = 0;
+
+# Check 'none'.
+my $none_positive = none { $_[0] < 0 } (1, 7, 3, 8, 9);
+$failed = 1 if ($none_positive == 0);
+
+my $none_gt_8 = none { $_[0] >= 8 } (1, 7

bug#28160: Support newer version of python

[Mathieu Lirzin]

Hello,

Mathieu Lirzin <m...@gnu.org> writes:

> Mathieu Lirzin <m...@gnu.org> writes:
>
>>>>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
>> From: Mathieu Lirzin <m...@gnu.org>
>> Date: Thu, 1 Feb 2018 13:51:03 +0100
>> Subject: [PATCH] python: Generate python interpreter list
>>
>> _AM_PYTHON_INTERPRETER_LIST is used by AM_PYTHON_PATH to autodetect
>> Python programs whose names correspond to a specific Python
>> version (e.g. python3.6).  Previously this list was updated manually.
>> The automatic support of newer versions (up to 4.0 excluded) fixes
>> bug#28160.
>>
>> * m4/python.m4 (am_py_min_ver, am_py_max_ver): New macros.
>> (_AM_PYTHON_INTERPRETER_LIST): Generate this list instead of hard-coding
>> it.  Implementation is taken from GNU Pyconfigure.
>> ---
>>  m4/python.m4 | 21 +
>>  1 file changed, 17 insertions(+), 4 deletions(-)
>
> Pushed as commit 1d60fb72168e62d33fe433380af621de64e22f23

This commit has brought the issue described in automake bug#30616 [1].

I initially was not happy with solution of manually defining future
versions, but after reflection it seems that the maintainability issue
of updating it manually doesn't worth the complexity of generating it
with M4.  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 <m...@gnu.org>
Date: Sat, 3 Mar 2018 12:01:13 +0100
Subject: [PATCH] python: Support future python version up to 3.9

This change fixes automake bug#28160.

Since AM_PYTHON_PATH macro takes no maximum version argument, there is
no need to generate _AM_PYTHON_INTERPRETER_LIST dynamically, like what
was previously done by the reverted commit
1d60fb72168e62d33fe433380af621de64e22f23.  We could rely on M4 to
generate this list statically however this is likely to be a complex
solution that would not improve maintainability.

* m4/python.m4 (_AM_PYTHON_INTERPRETER_LIST): Add 'python3.7',
'python3.8', and 'python3.9'.
---
 m4/python.m4 | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/m4/python.m4 b/m4/python.m4
index 58dd18761..63c0a0e04 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -36,11 +36,12 @@ AC_DEFUN([AM_PATH_PYTHON],
  [
   dnl Find a Python interpreter.  Python versions prior to 2.0 are not
   dnl supported. (2.0 was released on October 16, 2000).
-  dnl FIXME: Remove the need to hard-code Python versions here.
   m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
-[python python2 python3 python3.6 python3.5 python3.4 python3.3 python3.2 dnl
- python3.1 python3.0 python2.7 python2.6 python2.5 python2.4 python2.3 dnl
- python2.2 python2.1 python2.0])
+[python python2 python3 dnl
+ python3.9 python3.8 python3.7 python3.6 python3.5 python3.4 python3.3 dnl
+ python3.2 python3.1 python3.0 dnl
+ python2.7 python2.6 python2.5 python2.4 python2.3 python2.2 python2.1 dnl
+ python2.0])
 
   AC_ARG_VAR([PYTHON], [the Python interpreter])
 
-- 
2.16.2


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30616
-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30616: automake-1.16: aclocal is unable to process AM_PATH_PYTHON with variable as value

[Mathieu Lirzin]

Eric Blake <ebl...@redhat.com> 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): 
>>>> (0r36:PYTHON_+1) != (0*4)
>>>> autom4te-2.69: /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.
>
> I think it's more than just a bad m4 quoting issue, but a bad patch
> altogether;

Indeed.

> reverting it, and going back to a hand-maintained list (but where the
> hand-maintained list has a LOT more entries, covering the cases that
> the code generator was trying but failing to generate) may make the
> most sense.

I agree.  I guess the issues you described below could be fixed by
statically generating the list with M4, however it seems that the
maintainability/complexity balance of that solution would still be
questionable.

>  Looking at the commit in question:
>
>>
>> +++ b/m4/python.m4
>> @@ -36,11 +36,24 @@ AC_DEFUN([AM_PATH_PYTHON],
>>   [
>>dnl Find a Python interpreter.  Python versions prior to 2.0 are not
>>dnl supported. (2.0 was released on October 16, 2000).
>> -  dnl FIXME: Remove the need to hard-code Python versions here.
>> +  m4_define_default([am_py_min_ver], m4_ifval([$1], [$1], [2.0]))
>
> This defines an m4 variable to the value of $1...
>
>> +  dnl The arbitrary default maximum version.
>> +  m4_define_default([am_py_max_ver], [4.0])
>> +
>>m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
>> -[python python2 python3 python3.6 python3.5 python3.4 python3.3 python3.2 
>> dnl
>> - python3.1 python3.0 python2.7 python2.6 python2.5 python2.4 python2.3 dnl
>> - python2.2 python2.1 python2.0])
>> +[[python] \
>> + dnl If we want some Python 2 versions (min version <= 2.7),
>> + dnl also search for "python2".
>> + m4_if(m4_version_compare(am_py_min_ver, [2.8]), [-1], [python2], []) \
>
> ...and then tries to call m4_version_compare() on the expansion of
> that variable.  That works if $1 is an m4 literal, but fails miserably
> if $1 represents something that won't be known until shell time.  You
> could use AS_LITERAL_IF() to output different code (a version
> optimized for minimal output if everything is known up front at m4
> time, vs. a version that works later at shell time) - but it may be
> simpler to just always use a version that works at shell time rather
> than trying to optimize for minimal output when you have an
> m4-literal.
>
>> + [python3] \
>> + dnl Construct a comma-separated list of interpreter names (python2.6,
>> + dnl python2.7, etc). We only care about the first 3 characters of the
>> + dnl version strings (major-dot-minor; not
>> + dnl major-dot-minor-dot-bugfix[-dot-whatever])
>> + m4_foreach([py_ver],
>> +   m4_esyscmd_s(seq -s[[", "]] -f["[[%.1f]]"] m4_substr(am_py_max_ver, 
>> [0], [3]) -0.1 m4_substr(am_py_min_ver, [0], [3])),
>
> Furthermore, this use of m4_esyscmd_s() is non portable - 'seq' is not
> required by GNU Coding Standards, so you cannot assume that it exists
> on the machine of the developer running 'automake' (if you keep it as
> an m4-time code generation loop), and especially not on all machines
> (if you rewrite it to be a shell-friendly loop that works even if $1
> is a shell variable, by deferring to ./configure or make time).
>
>> +   dnl Remove python2.8 and python2.9 since they will never exist
>> +   [m4_bmatch(py_ver, [2.[89]], [], [python]py_ver)])])
>>  

I have reverted commit 1d60fb72168e62d33fe433380af621de64e22f23 [1].

Since this commit was fixing automake bug#28160, I have reopened this
bug.

Thanks for your help.

[1] 
http://git.savannah.gnu.org/cgit/automake.git/commit/?id=4ef6c2d17d2805fd6f84af012ddc44edd7650789

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: GNU Automake 1.16 released

[Mathieu Lirzin]

Hello,

Eric Dorland <e...@kuroneko.ca> writes:

> Can this release be tagged in the git repository?
>
> * Mathieu Lirzin (m...@gnu.org) wrote:
>> We are pleased to announce the GNU Automake 1.16 minor release.

Done.

Thanks for the reminder.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH] install-sh: avoid (low risk) race in /tmp

[Mathieu Lirzin]

Hello thomas,

Thomas Deutschmann <whi...@gentoo.org> writes:

> Pavel Raiskup submitted a patch to avoid a (low risk) race
> in /tmp in April 2015 [1] which still isn't merged.
>
> Was there a reason or was it just forgotten? Maybe we can
> add it now?

Yes it has just been forgotten, if the patch is safe then yes we can
apply it for 1.16.1.

> It is currently present in Red Hat, Debian and Gentoo 
> (haven't checked more distributions).
>
> See also:
> =
> [1] https://lists.gnu.org/archive/html/automake-patches/2015-04/msg1.html

I will take a closer look in the following days.

Thanks for reminding us.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Automake 1.16 build failure

[Mathieu Lirzin]

Hello,

Andreas Schwab <sch...@linux-m68k.org> writes:

> $ make -j4
>   GEN  bin/automake
>   GEN  bin/aclocal
>   GEN  t/ax/shell-no-trail-bslash
>   GEN  t/ax/cc-no-c-o
>   GEN  runtest
>   GEN  doc/aclocal.1
>   GEN  doc/automake.1
>   GEN  lib/Automake/Config.pm
>   GEN  t/ax/test-defs.sh
>   GEN  bin/aclocal-1.16
>   GEN  bin/automake-1.16
>   GEN  doc/aclocal-1.16.1
>   GEN  doc/automake-1.16.1
> help2man: can't get `--help' info from automake-1.16
> Try `--no-discard-stderr' if option outputs to stderr
> Makefile:3694: recipe for target 'doc/automake-1.16.1' failed
> make: *** [doc/automake-1.16.1] Error 255
> make: *** Waiting for unfinished jobs
>
> $ ./pre-inst-env automake-1.16 --help
> "none" is not exported by the List::Util module
> Can't continue after import errors at 
> /home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76.
> BEGIN failed--compilation aborted at 
> /home/abuild/rpmbuild/BUILD/automake-1.16/bin/automake-1.16 line 76.
>
> Andreas.

What is the Perl version used?

Can you open a bug report on <bug-autom...@gnu.org> for this issue?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30616: automake-1.16: aclocal is unable to process AM_PATH_PYTHON with variable as value

[Mathieu Lirzin]

Hello,

Thomas Deutschmann <whi...@gentoo.org> writes:

> re-sending to bug-automake (first mail was accidentally sent
> to the normal mailing list).
>
> With automake-1.16, code like
>
>> AM_PATH_PYTHON([$PYTHON_VERSION])
>
> or
>
>> AM_PATH_PYTHON([$PYTHON_MIN_VERSION])
>
> as found in
>
> https://gitlab.com/cryptsetup/cryptsetup/blob/master/configure.ac#L506
> https://github.com/ImageMagick/PythonMagick/blob/master/configure.ac#L42
>
> doesn't work anymore:
>
>> * aclocal *
>> * PWD: /var/tmp/portage/sys-fs/cryptsetup-2.0.1/work/cryptsetup-2.0.1
>> * aclocal -I m4
>> 
>> /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): 
>> (0r36:PYTHON_+1) != (0*4)
>> autom4te-2.69: /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

Re: manual: Why use 'maude' as the example program name?

[Mathieu Lirzin]

Tom Tromey <t...@tromey.com> writes:

>>>>>> "Jonas" == Jonas Thiem <jonas@thiem.email> writes:
>
> Jonas> Disclaimer: I haven't read this part of the docs myself. But for what
> Jonas> it's worth, I think Maude looks a bit like a misspelling of Make and
> Jonas> doesn't stick out that well, compared to "exampleprog" or something.
>
> One such section starts:
>
>In the list below, we use the name “maude” to refer to the program or
> library.  In your ‘Makefile.am’ you would replace this with the
> canonical name of your program.  This list also refers to “maude” as a
> program, but in general the same rules apply for both static and dynamic
> libraries; the documentation below notes situations where programs and
> libraries differ.
>

FWIW, I think using “maude” with the above explanation is clear enough.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

GNU Automake 1.16 released

[Mathieu Lirzin]

We are pleased to announce the GNU Automake 1.16 minor release.

This release follows 1.15.1 which was made 8 months ago.

See below for the detailed list of changes since the
previous version, as summarized by the NEWS file.

Download here:

  https://ftp.gnu.org/gnu/automake/automake-1.16.tar.gz
  https://ftp.gnu.org/gnu/automake/automake-1.16.tar.xz

Please report bugs and problems to ,
and send general comments and feedback to .

Thanks to everyone who has reported problems, contributed
patches, and helped testing Automake!

-*-*-*-

* WARNING: Future backward-incompatibilities!

  - Makefile recipes generated by Automake 2.0 will expect to use an
'rm' program that doesn't complain when called without any non-option
argument if the '-f' option is given (so that commands like "rm -f"
and "rm -rf" will act as a no-op, instead of raising usage errors).
This behavior of 'rm' is very widespread in the wild, and it will be
required in the next POSIX version:

  

Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
that the default 'rm' program in PATH satisfies this requirement,
aborting the configure process if this is not the case.  For the
moment, it's still possible to force the configuration process to
succeed even with a broken 'rm', that that will no longer be the case
for Automake 2.0.

  - Automake 2.0 will require Autoconf 2.70 or later (which is still
unreleased at the moment of writing, but is planned to be released
before Automake 2.0 is).

  - Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file.  You are advised to start using the
recommended name 'configure.ac' instead, ASAP.

  - The ACLOCAL_AMFLAGS special make variable will be fully deprecated in
Automake 2.0: it will raise warnings in the "obsolete" category (but
still no hard error of course, for compatibilities with the many, many
packages that still relies on that variable).  You are advised to
start relying on the new Automake support for AC_CONFIG_MACRO_DIRS
instead (which was introduced in Automake 1.13).

  - Automake 2.0 will remove support for automatic dependency tracking
with the SGI C/C++ compilers on IRIX.  The SGI depmode has been
reported broken "in the wild" already, and we don't think investing
time in debugging and fixing is worthwhile, especially considering
that SGI has last updated those compilers in 2006, and retired
support for them in December 2013:


  - Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
(support for them was offered by relying on the DJGPP project).
Note however that both Cygwin and MSYS/MinGW on modern Windows
versions will continue to be fully supported.

  - Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 2.0.  There still is no
certainty about this though: we'd first like to wait and see
whether future Autoconf versions will be enhanced to guarantee
that such a shell is always found and provided by the checks in
./configure.

  - Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros.  For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-2.0/vala.m4').



New in 1.16:

* Miscellaneous changes

  - When subdir-objects is in effect, Automake will now construct
shorter object file names when no programs and libraries name
clashes are encountered.  This should make the discouraged use of
'foo_SHORTNAME' unnecessary in many cases.

* Bugs fixed:

  - Automatic dependency tracking has been fixed to work also when the
'subdir-object' option is used and some 'foo_SOURCES' definition
contains unexpanded references to make variables, as in, e.g.:

a_src = sources/libs/aaa
b_src = sources/bbb
foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c

With such a setup, the created makefile fragment containing dependency
tracking information will be correctly placed under the directories
named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than
mistakenly under directories named (literally!) '$(src_a)/.deps' and
'$(src_b)/.deps' (this was the first part of automake bug#13928).

Notice that in order to fix this bug we had to slightly change the

Re: Ideas for Summer of Code 2018

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> writes:

> Google is accepting organization applications for the next Summer of
> Code [1] and as usual GNU is going to apply for it.  Let's start thinking
> about a list of ideas for the next Summer of Code and potential mentors.

Here is another project idea I would like to propose:

Parse Makefile.am using an Abstract Syntax Tree

   When reading its input files automake doesn't clearly separate the
   parsing, semantic analysis, and code generation phases. This design
   does not help with the separation of concerns and makes the code hard
   to test. The objective of this project is to write a parser for
   Makefile.am files that generates an Abstract Syntax Tree (AST) That can
   be used independently of the Makefile.in files generation process.

   Skills: Understanding of the classical compilation phases. Basic
   knowledge of Perl
   Mentor: Mathieu Lirzin
   Contact: automake@gnu.org

The list of the proposed projects is hosted here:
<https://www.gnu.org/software/soc-projects/ideas-2018.html#automake>

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Supporting multiple python runtimes with automake

[Mathieu Lirzin]

Hi Yuval,

Yuval Turgeman <yuv...@redhat.com> writes:

> Thanks for the feedback ! What you described is what we are doing
> today, it does the job nicely, I just thought it would be nice to
> avoid 2 calls. Honestly, both VPATH and my patch feel a little hackish
> to me, and the existing way is not really that painful, I guess. Your
> call, I will not be offended if this gets rejected, as I wasnt 100%
> sure I should post this anyway, but since I already played with it one
> night, I thought why not :)

I would rather stick to a single AM_PATH_PYTHON for Python.  :-)

Thanks for your patch anyway.  If you have other ideas regarding how
Python support in Automake could be improved, feel free to share your
ideas on <autom...@gnu.org> or your patches on this list.

Sorry for the delay.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[PATCH] bin: Rely only on the shebang line

[Mathieu Lirzin]

Previously ‘automake’ and ‘aclocal’ were handling the case of being
interpreted as a Shell script by using a hack leveraging the fact that
Shell and Perl has a compatible syntax intersection allowing those
scripts to launch ‘perl’ from the shell.

* bin/aclocal.in: Remove cryptic launching hack.
* bin/automake.in: Likewise.
---
 bin/aclocal.in  | 8 +---
 bin/automake.in | 7 +--
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/bin/aclocal.in b/bin/aclocal.in
index b3715d9c6..722affa55 100644
--- a/bin/aclocal.in
+++ b/bin/aclocal.in
@@ -1,12 +1,6 @@
 #!@PERL@ -w
-# -*- perl -*-
+# aclocal - create aclocal.m4 by scanning configure.ac  -*- perl -*-
 # @configure_input@
-
-eval 'case $# in 0) exec @PERL@ -S "$0";; *) exec @PERL@ -S "$0" "$@";; esac'
-if 0;
-
-# aclocal - create aclocal.m4 by scanning configure.ac
-
 # Copyright (C) 1996-2018 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
diff --git a/bin/automake.in b/bin/automake.in
index 16fb45182..8aafe4b58 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1,11 +1,6 @@
 #!@PERL@ -w
-# -*- perl -*-
+# automake - create Makefile.in from Makefile.am-*- perl -*-
 # @configure_input@
-
-eval 'case $# in 0) exec @PERL@ -S "$0";; *) exec @PERL@ -S "$0" "$@";; esac'
-if 0;
-
-# automake - create Makefile.in from Makefile.am
 # Copyright (C) 1994-2018 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
-- 
2.16.1

bug#30556: Python tests should run with multiple python versions

[Mathieu Lirzin]

The test suite applies its tests only with the ‘python’ executable which
is an issue since on most systems it corresponds to ‘python2’, and for
systems having only ‘python3’ the tests are simply skipped.

Moreover, when ‘python’ corresponds to ‘python3’ as it is the case on
distributions not 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

bug#30126: Do not require “ltmain.sh” for out-of-tree libtool

[Mathieu Lirzin]

Hello,

Mathieu Lirzin <m...@gnu.org> writes:

> Mathieu Lirzin <m...@gnu.org> writes:
>
>>>>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
>> From: Paolo Bonzini <bonz...@gnu.org>
>> 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 see LT_SUPPORTED_TAG, it assumes an old libtool
>> that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
>> does not use Libtool's configure.ac macros this check gets a
>> false positive.  Do not require ltmain.sh if no Libtool macro is
>> found in configure.ac.
>>
>> * bin/automake.in ($libtool_bundled): New variable.
>> (handle_libtool): Do not require libtool files if libtool is not being
>> bundled.
>> (scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
>> ---
>
> Would you have some time to allocate on a test for this patch in the
> following days/weeks?  I would like to be able to merge it before
> releasing Automake 1.16?

I have implemented the test myself, however I still don't understand how
the following scenario could reasonably happen.  So could you explain me
how such configuration could happen so that I can include it as a
rationale describing the test?

Thanks.

>From 196fc03864028e022b7a590b50c5711c6754e42b Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <m...@gnu.org>
Date: Tue, 20 Feb 2018 11:14:54 +0100
Subject: [PATCH] =?UTF-8?q?tests:=20Add=20=E2=80=9Ct/libtool-when-required?=
 =?UTF-8?q?.sh=E2=80=9D?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* t/libtool-when-required.sh: New failing test for bug#30126.
* t/list-of-tests.mk (handwritten_TESTS, XFAIL_TESTS): Add it.
---
 t/libtool-when-required.sh | 36 
 t/list-of-tests.mk |  2 ++
 2 files changed, 38 insertions(+)
 create mode 100644 t/libtool-when-required.sh

diff --git a/t/libtool-when-required.sh b/t/libtool-when-required.sh
new file mode 100644
index 0..d5f93814f
--- /dev/null
+++ b/t/libtool-when-required.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+# Copyright (C) 2018 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+# Make sure Automake does not require libtool files when no libtool macros are
+# used.
+
+. test-init.sh
+
+cat >> configure.ac <<'END'
+AC_PROG_CC
+AC_SUBST([LIBTOOL], [libtool])
+AM_PROG_AR
+AC_OUTPUT
+END
+
+cat >> Makefile.am <<'END'
+lib_LTLIBRARIES = libfoo.la
+END
+
+$ACLOCAL
+AUTOMAKE_run -d 'should not complain about missing ltmain.sh' -- --add-missing
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 271bfb573..8fdd076aa 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -38,6 +38,7 @@ t/override-conditional-pr13940.sh \
 t/dist-pr109765.sh \
 t/instdir-cond2.sh \
 t/java-nobase.sh \
+t/libtool-when-required.sh \
 t/objext-pr10128.sh \
 t/remake-timing-bug-pr8365.sh \
 t/lex-subobj-nodep.sh \
@@ -638,6 +639,7 @@ t/libtool8.sh \
 t/libtool9.sh \
 t/libtoo10.sh \
 t/libtoo11.sh \
+t/libtool-when-required.sh \
 t/license.sh \
 t/license2.sh \
 t/link_c_cxx.sh \
-- 
2.16.1


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: bug#30126: Do not require “ltmain.sh” for out-of-tree libtool

[Mathieu Lirzin]

Hello,

Mathieu Lirzin <m...@gnu.org> writes:

> Mathieu Lirzin <m...@gnu.org> writes:
>
>>>>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
>> From: Paolo Bonzini <bonz...@gnu.org>
>> 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 see LT_SUPPORTED_TAG, it assumes an old libtool
>> that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
>> does not use Libtool's configure.ac macros this check gets a
>> false positive.  Do not require ltmain.sh if no Libtool macro is
>> found in configure.ac.
>>
>> * bin/automake.in ($libtool_bundled): New variable.
>> (handle_libtool): Do not require libtool files if libtool is not being
>> bundled.
>> (scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
>> ---
>
> Would you have some time to allocate on a test for this patch in the
> following days/weeks?  I would like to be able to merge it before
> releasing Automake 1.16?

I have implemented the test myself, however I still don't understand how
the following scenario could reasonably happen.  So could you explain me
how such configuration could happen so that I can include it as a
rationale describing the test?

Thanks.

>From 196fc03864028e022b7a590b50c5711c6754e42b Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <m...@gnu.org>
Date: Tue, 20 Feb 2018 11:14:54 +0100
Subject: [PATCH] =?UTF-8?q?tests:=20Add=20=E2=80=9Ct/libtool-when-required?=
 =?UTF-8?q?.sh=E2=80=9D?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* t/libtool-when-required.sh: New failing test for bug#30126.
* t/list-of-tests.mk (handwritten_TESTS, XFAIL_TESTS): Add it.
---
 t/libtool-when-required.sh | 36 
 t/list-of-tests.mk |  2 ++
 2 files changed, 38 insertions(+)
 create mode 100644 t/libtool-when-required.sh

diff --git a/t/libtool-when-required.sh b/t/libtool-when-required.sh
new file mode 100644
index 0..d5f93814f
--- /dev/null
+++ b/t/libtool-when-required.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+# Copyright (C) 2018 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+# Make sure Automake does not require libtool files when no libtool macros are
+# used.
+
+. test-init.sh
+
+cat >> configure.ac <<'END'
+AC_PROG_CC
+AC_SUBST([LIBTOOL], [libtool])
+AM_PROG_AR
+AC_OUTPUT
+END
+
+cat >> Makefile.am <<'END'
+lib_LTLIBRARIES = libfoo.la
+END
+
+$ACLOCAL
+AUTOMAKE_run -d 'should not complain about missing ltmain.sh' -- --add-missing
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 271bfb573..8fdd076aa 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -38,6 +38,7 @@ t/override-conditional-pr13940.sh \
 t/dist-pr109765.sh \
 t/instdir-cond2.sh \
 t/java-nobase.sh \
+t/libtool-when-required.sh \
 t/objext-pr10128.sh \
 t/remake-timing-bug-pr8365.sh \
 t/lex-subobj-nodep.sh \
@@ -638,6 +639,7 @@ t/libtool8.sh \
 t/libtool9.sh \
 t/libtoo10.sh \
 t/libtoo11.sh \
+t/libtool-when-required.sh \
 t/license.sh \
 t/license2.sh \
 t/link_c_cxx.sh \
-- 
2.16.1


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30335: ‘make uninstall’ exceeds command-line length limit

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> 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 <m...@gnu.org>
Date: Sun, 4 Feb 2018 00:09:31 +0100
Subject: [PATCH] python: Avoid exceeding command-line length limit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With Python implementations following PEP-3174, a large number of files
are installed in the ‘__pycache__’ directory.  As a consequence
“t/instmany-python.sh” test was failing due to the
‘uninstall-pythonPYTHON’ target deleting installed files in a single
‘rm’ command.  Doing that in multiple steps avoids exceeding the
command-line length limit.  This fixes bug#30335.

* lib/am/python.am (uninstall-%DIR%PYTHON): For byte-compiled files
installed in '__pycache__' directory, uninstall them by batch of 40.
[?FIRST?] (am__pep3147_tweak): Adapt.
---
 lib/am/python.am | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/lib/am/python.am b/lib/am/python.am
index e29ecfcd0..21e6f842c 100644
--- a/lib/am/python.am
+++ b/lib/am/python.am
@@ -97,7 +97,7 @@ endif %?INSTALL%
 if %?INSTALL%
 
 ?FIRST?am__pep3147_tweak = \
-?FIRST?  sed -e 's|\.py$$||' -e 's|[^/]*$$|__pycache__/&.*.py|'
+?FIRST?  sed -e 's|\.py$$||' -e 's|[^/]*$$|&.*.pyc\n&.*.pyo|'
 
 .PHONY uninstall-am: uninstall-%DIR%PYTHON
 uninstall-%DIR%PYTHON:
@@ -108,26 +108,19 @@ uninstall-%DIR%PYTHON:
 	test -n "$$py_files" || exit 0; \
 	dir='$(DESTDIR)$(%NDIR%dir)'; \
 ## Also remove the .pyc and .pyo byte compiled versions.
-## This is somewhat tricky, because for newer pythons we have to take
-## PEP-3147 into account.
 	pyc_files=`echo "$$py_files" | sed 's|$$|c|'`; \
 	pyo_files=`echo "$$py_files" | sed 's|$$|o|'`; \
-	py_files_pep3147=`echo "$$py_files" | $(am__pep3147_tweak)`; \
-	echo "$$py_files_pep3147";\
-	pyc_files_pep3147=`echo "$$py_files_pep3147" | sed 's|$$|c|'`; \
-	pyo_files_pep3147=`echo "$$py_files_pep3147" | sed 's|$$|o|'`; \
 	st=0; \
-	for files in \
-	  "$$py_files" \
-	  "$$pyc_files" \
-	  "$$pyo_files" \
-## Installation of '.py' files is not influenced by PEP-3147, so it
-## is correct *not* to have $pyfiles_pep3147 here.
-	  "$$pyc_files_pep3147" \
-	  "$$pyo_files_pep3147" \
-	; do \
+	for files in "$$py_files" "$$pyc_files" "$$pyo_files"; do \
 	  $(am__uninstall_files_from_dir) || st=$$?; \
 	done; \
+## This is somewhat tricky, because for newer pythons we have to take PEP-3147
+## into account.  Avoid exceeding the command-line length limit.
+	dir='$(DESTDIR)$(%NDIR%dir)/__pycache__'; \
+	echo "$$py_files" | $(am__pep3147_tweak) | $(am__base_list) | \
+	  while read files; do \
+	$(am__uninstall_files_from_dir) || st=$$?; \
+	  done || exit $$?; \
 	exit $$st
 endif %?INSTALL%
 
-- 
2.16.1


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#29638: Same five tests fail with 1.15 on RHEL 7.4

[Mathieu Lirzin]

Hello,

Mathieu Lirzin <m...@gnu.org> writes:

>>From 83d5d37bc8f0adb0e20a6fe7ab68029d2479dd32 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <m...@gnu.org>
> Date: Thu, 18 Jan 2018 11:19:13 +0100
> Subject: [PATCH] tests: Don't check 'Getopt::Long' corner cases
>
> Depending on the installed 'Getopt::Long' perl module, command-line
> handling may vary a bit.  As a consequence we prefer not to check
> command-line corners cases.  This change fixes automake bug#29638.
>
> * t/aclocal.sh (am_create_testdir): Don't expect "--versi" to be
> interpreted as "--version".
> * t/automake-cmdline.tap: Don't expect "--vers" to be interpreted as
> "--version" and things after "--" to be interpreted as file arguments.
> (do_check): Display the actual command output.
> * t/maken3.sh (check_targets): "--force" is not a documented option, so
> don't use it.
> ---

I have pushed this in commit 903a80e0def90b88c1e4eead353af126a31a5422.

Feel free to reopen this bug if the problem persists.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28160: Support newer version of python

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> writes:

>>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <m...@gnu.org>
> Date: Thu, 1 Feb 2018 13:51:03 +0100
> Subject: [PATCH] python: Generate python interpreter list
>
> _AM_PYTHON_INTERPRETER_LIST is used by AM_PYTHON_PATH to autodetect
> Python programs whose names correspond to a specific Python
> version (e.g. python3.6).  Previously this list was updated manually.
> The automatic support of newer versions (up to 4.0 excluded) fixes
> bug#28160.
>
> * m4/python.m4 (am_py_min_ver, am_py_max_ver): New macros.
> (_AM_PYTHON_INTERPRETER_LIST): Generate this list instead of hard-coding
> it.  Implementation is taken from GNU Pyconfigure.
> ---
>  m4/python.m4 | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)

Pushed as commit 1d60fb72168e62d33fe433380af621de64e22f23

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30352: BUG report using autoconf…

[Mathieu Lirzin]

Hello,

aotto <aotto1...@t-online.de> 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
<bug-autoc...@gnu.org> instead.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28160: Support newer version of python

[Mathieu Lirzin]

Hello,

Mathieu Lirzin <m...@gnu.org> 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-code them.
>
> It seems that GNU Pyconfigure has already found a way to build that list
> dynamically in m4.  Please see PC_PROG_PYTHON macro here:
>
>   https://git.savannah.gnu.org/cgit/pyconfigure.git/tree/src/m4/python.m4

I have adapted this to fit Automake context.  I am going to apply the
following patch in the following days.  Comments welcome.

>From 1d60fb72168e62d33fe433380af621de64e22f23 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <m...@gnu.org>
Date: Thu, 1 Feb 2018 13:51:03 +0100
Subject: [PATCH] python: Generate python interpreter list

_AM_PYTHON_INTERPRETER_LIST is used by AM_PYTHON_PATH to autodetect
Python programs whose names correspond to a specific Python
version (e.g. python3.6).  Previously this list was updated manually.
The automatic support of newer versions (up to 4.0 excluded) fixes
bug#28160.

* m4/python.m4 (am_py_min_ver, am_py_max_ver): New macros.
(_AM_PYTHON_INTERPRETER_LIST): Generate this list instead of hard-coding
it.  Implementation is taken from GNU Pyconfigure.
---
 m4/python.m4 | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/m4/python.m4 b/m4/python.m4
index 58dd18761..d6dda1363 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -36,11 +36,24 @@ AC_DEFUN([AM_PATH_PYTHON],
  [
   dnl Find a Python interpreter.  Python versions prior to 2.0 are not
   dnl supported. (2.0 was released on October 16, 2000).
-  dnl FIXME: Remove the need to hard-code Python versions here.
+  m4_define_default([am_py_min_ver], m4_ifval([$1], [$1], [2.0]))
+  dnl The arbitrary default maximum version.
+  m4_define_default([am_py_max_ver], [4.0])
+
   m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
-[python python2 python3 python3.6 python3.5 python3.4 python3.3 python3.2 dnl
- python3.1 python3.0 python2.7 python2.6 python2.5 python2.4 python2.3 dnl
- python2.2 python2.1 python2.0])
+[[python] \
+ dnl If we want some Python 2 versions (min version <= 2.7),
+ dnl also search for "python2".
+ m4_if(m4_version_compare(am_py_min_ver, [2.8]), [-1], [python2], []) \
+ [python3] \
+ dnl Construct a comma-separated list of interpreter names (python2.6,
+ dnl python2.7, etc). We only care about the first 3 characters of the
+ dnl version strings (major-dot-minor; not
+ dnl major-dot-minor-dot-bugfix[-dot-whatever])
+ m4_foreach([py_ver],
+   m4_esyscmd_s(seq -s[[", "]] -f["[[%.1f]]"] m4_substr(am_py_max_ver, [0], [3]) -0.1 m4_substr(am_py_min_ver, [0], [3])),
+   dnl Remove python2.8 and python2.9 since they will never exist
+   [m4_bmatch(py_ver, [2.[89]], [], [python]py_ver)])])
 
   AC_ARG_VAR([PYTHON], [the Python interpreter])
 
-- 
2.16.1


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Supporting multiple python runtimes with automake

[Mathieu Lirzin]

Yuval Turgeman <yuv...@redhat.com> writes:

> Because when I want to package an rpm, I have a single %build and
> %install in my spec, so my second call to configure will override the
> first, and then i will need to run make install. So the process would
> be result in something like
>
> (from %build)
> configure PYTHON=/usr/bin/python2
> make
> configure PYTHON=/usr/bin/python3
> make
> (from %install)
> make install
>
> which wont work (unless we move make install to %build i guess). With
> this patch, a single configure would nail both pythons, and make
> install would install the relevant files to their correct location.

What could be done is to use out-of-tree “VPATH” builds [1] to configure
and build with both python versions in different directories in the
‘%build’ phase and run ‘make install’ in each of these directories in
the ’%install’ phase.

Maybe something like this (totally untested :-)):
--8<---cut here---start->8---
%build
mkdir py2 && cd py2
../%configure PYTHON=/path/to/python2
%make_build
cd ..
mkdir py3 && cd py3
../%configure PYTHON=/path/to/python3
%make_build
cd ..

%install
%make_install -C py2
%make_install -C py3
--8<---cut here---end--->8---

It seems not ideal to handle distro specific packaging guidelines on the
upstream configuration side.  As a consequence I would rather avoid
adding macros to be run at configure time.

WDYT?

[1] https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Supporting multiple python runtimes with automake

[Mathieu Lirzin]

Hello,

Yuval Turgeman <yuv...@redhat.com> writes:

> On Tue, Jan 30, 2018 at 2:22 PM, Sandro Bonazzola <sbona...@redhat.com>
> wrote:
>
>> 2018-01-30 11:26 GMT+01:00 Yuval Turgeman <yturg...@redhat.com>:
>>
>>> I added 2 macros (AM_PATH_PYTHON2 and AM_PATH_PYTHON3) to support both
>>> python2 and python3 on the same system.  It works in the same way that
>>> AM_PATH_PYTHON works (just a small wrapper around it).  Please notice that
>>> AM_PATH_PYTHON and AM_PATH_PYTHONx can't be called together.
>>>
>>> The motive for doing this is Fedora Packaging Guidelines for Python (
>>> https://fedoraproject.org/wiki/Packaging:Python) which requires a
>>> package to be built for both runtimes.
>>>
>>
>> Are you planning to use this for installing python2 and python3 artifacts
>> in a single make install call instead of having to go through 2 runs of
>> configure / make / make install ?
>>
>
> Yes, the alternative to this is to run everything twice with a different
> `PYTHON=` value, unless I'm missing something and there's an easier way
> that would make this patch irrelevant.

Could you explain why re-running the configuration phase with different
‘PYTHON’ values does not fit your use-case?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Why doesn't install-strip strip shared libraries sometimes

[Mathieu Lirzin]

Yuri <y...@rawbw.com> writes:

> I came across one project in which install-strip doesn't strip the
> shared library: liblink-grammar.so in
> https://github.com/opencog/link-grammar
>
> As an opposite example, showing the normal behavior, install-strip
> strips libexpat.so in
> https://github.com/libexpat/libexpat/tree/master/expat.
>
> What might prevent install-strip from stripping liblink-grammar.so?

I have looked at the issue you have on the link-grammar bug-tracker [1].  I
would need more information to diagnose the problem.  Could you provide the
“config.log” and the output of ‘make install-strip V=1’ for both projects?

[1] https://github.com/opencog/link-grammar/issues/645

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: How does one report bugs for automake?

[Mathieu Lirzin]

Hello,

Yuri <y...@rawbw.com> writes:

> I recently reported a bug about install-strip not stripping the shared
> library for one particular project, and there is no answer.
>
> Is this ML the right place to report bugs?

This is the correct mailing-list for asking questions why Automake
behave a certain way, which seems what your previous email is about.

Next time for such question, please ask it in the same thread you have
previously opened.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30127: Re[2]: bug#30127: ICC: 'entry point must be defined' error for shared builds on Windows

[Mathieu Lirzin]

sav...@ukr.net writes:

> In case you're interested, there is a patch to 'lib/ar-lib', which I use for 
> libiconv builds using Windows ICC:
> ===
> diff --git a/build-aux/ar-lib b/build-aux/ar-lib
> index 463b9ec..3cfddbc 100644
> --- a/build-aux/ar-lib
> +++ b/build-aux/ar-lib
> @@ -127,8 +127,10 @@ do
> fi
> case $1 in
> -lib | -LIB \
> + | -xilib | -XILIB \
> | -ltcg | -LTCG \
> | -machine* | -MACHINE* \
> + | -nologo | -NOLOGO \
> | -subsystem* | -SUBSYSTEM* \
> | -verbose | -VERBOSE \
> | -wx* | -WX* )
> ===
> since ICC linker 'xilink' and librarian 'xilib' are just a wrappers to MSVC 
> 'link' and librarian 'lib' respectively, and ' -nologo ' use reduces noise in 
> stderr.
>
> CC: Jonathan L Peyton,
> as Author of patch for 'compile', mentioned above. In case he'll be 
> interested to make a review aor join this discussion.
>
> Odd, that current 'ar-lib' implementation covers only a part of MSVC 'lib' 
> flags:
> ===
> c:\>lib /?
> Microsoft (R) Library Manager Version 14.12.25830.2
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> usage: LIB [options] [files]
>
> options:
>
> /DEF[:filename]
> /ERRORREPORT:{NONE|PROMPT|QUEUE|SEND}
> /EXPORT:symbol
> /EXTRACT:membername
> /INCLUDE:symbol
> /LIBPATH:dir
> /LIST[:filename]
> /LTCG
> /MACHINE:{ARM|ARM64|EBC|X64|X86}
> /NAME:filename
> /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]
> ===
>
> Wondering, what was a reason for this.

I am definitely not competent for reviewing Windows related stuff.  So
that would be great if Jonathan or anyone with more experience with
‘ar-lib’ could help reviewing this patch.

Thanks for your patch.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30172: dvi, ps, and pdf targets use AM_MAKEINFOFLAGS

[Mathieu Lirzin]

The test suite fails for “t/txinfo-many-output-formats.sh” and
“t/txinfo-many-output-formats-vpath.sh”.

  $ make check \
  TESTS="t/txinfo-many-output-formats.sh 
t/txinfo-many-output-formats-vpath.sh"



test-suite.log
Description: Binary data

The following patch makes the tests pass.

diff --git a/t/txinfo-many-output-formats-vpath.sh b/t/txinfo-many-output-formats-vpath.sh
index 331f57255..114ddc2ef 100644
--- a/t/txinfo-many-output-formats-vpath.sh
+++ b/t/txinfo-many-output-formats-vpath.sh
@@ -155,6 +155,9 @@ test ! -e share/$me/html/main.html
 test ! -e share/$me/html/main2.html
 test ! -e share/$me/html/main3.html
 
+# Restore the makefile without a broken AM_MAKEINFOFLAGS definition.
+cp -f $srcdir/Makefile.sav $srcdir/Makefile.am
+
 $MAKE dvi
 test -f main.dvi
 test -f sub/main2.dvi
@@ -198,8 +201,6 @@ test ! -e share/$me/pdf/main2.pdf
 test ! -e share/$me/pdf/main3.pdf
 test ! -e share/$me/pdf/hello
 
-# Restore the makefile without a broken AM_MAKEINFOFLAGS definition.
-cp -f $srcdir/Makefile.sav $srcdir/Makefile.am
 using_gmake || $MAKE Makefile
 $MAKE distcheck
 
diff --git a/t/txinfo-many-output-formats.sh b/t/txinfo-many-output-formats.sh
index 978417e60..65bbd360d 100644
--- a/t/txinfo-many-output-formats.sh
+++ b/t/txinfo-many-output-formats.sh
@@ -156,6 +156,9 @@ test ! -e share/$me/html/main.html
 test ! -e share/$me/html/main2.html
 test ! -e share/$me/html/main3.html
 
+# Restore the makefile without a broken AM_MAKEINFOFLAGS definition.
+cp -f $srcdir/Makefile.sav $srcdir/Makefile.am
+
 $MAKE dvi
 test -f main.dvi
 test -f sub/main2.dvi
@@ -199,8 +202,6 @@ test ! -e share/$me/pdf/main2.pdf
 test ! -e share/$me/pdf/main3.pdf
 test ! -e share/$me/pdf/hello
 
-# Restore the makefile without a broken AM_MAKEINFOFLAGS definition.
-cp -f $srcdir/Makefile.sav $srcdir/Makefile.am
 using_gmake || $MAKE Makefile
 $MAKE distcheck
 
The reason is that ‘texi2dvi’ is used by the dvi, ps, and pdf targets.
‘texi2dvi’ uses MAKEINFO internally which Automake augments with
AM_MAKEINFOFLAGS.  See the following snippet from the generated
Makefile:

--8<---cut here---start->8---
.texi.dvi:

$(AM_V_TEXI2DVI)TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I 
$(srcdir)' \
$(TEXI2DVI) $(AM_V_texinfo) --build-dir=$(@:.dvi=.t2d) -o $@ 
$(AM_V_texidevnull) \
$<
--8<---cut here---end--->8---

Whereas the manual claims that AM_MAKEINFOFLAGS should be used only when
building ‘.info’ files:

--8<---cut here---start->8---
‘AM_MAKEINFOFLAGS’
‘AM_MAKEINFOHTMLFLAGS’
 Maintainer flags passed to each ‘makeinfo’ invocation.  Unlike
 ‘MAKEINFOFLAGS’, these variables are meant to be defined by
 maintainers in ‘Makefile.am’.  ‘$(AM_MAKEINFOFLAGS)’ is passed to
 ‘makeinfo’ when building ‘.info’ files; and
 ‘$(AM_MAKEINFOHTMLFLAGS)’ is used when building ‘.html’ files.
--8<---cut here---end--->8---

Here is what could be done:

  1. Fix the manual to state that AM_MAKEINFOFLAGS is used for every
 non-html documentation target.

  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

bug#20031: GNU Automake 1.15 fails on three "yacc" cxx related tests on Solaris 10 AMD64

[Mathieu Lirzin]

Hello,

Those test failures are/were happening because IIUC Solaris 
header declares malloc, free, exit only in the std namespace [1].

"dcla...@blastwave.org" <dcla...@blastwave.org> writes:

> /opt/solarisstudio12.4/bin/CC -DPACKAGE_NAME=\"yacc-cxx\" 
> -DPACKAGE_TARNAME=\"yacc-cxx\" -DPACKAGE_VERSION=\"1.0\" 
> -DPACKAGE_STRING=\"yacc-cxx\ 1.0\" -DPACKAGE_BUGREPORT=\"\" 
> -DPACKAGE_URL=\"\" -DPACKAGE=\"yacc-cxx\" -DVERSION=\"1.0\" -I.
> -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
> -D_LARGEFILE64_SOURCE  -dalign -erroff=%none -errtags=yes -ftrap=%none -g 
> -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xtarget=opteron -xdepend=no 
> -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%frameptr -xs 
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -c -o parse1.o 
> parse1.cc
> "parse1.cc", line 1053: Error: The function "malloc" must have a prototype.
> "parse1.cc", line 1060: Error: The function "free" must have a prototype.
> "parse1.yy", line 10: Error: The function "exit" must have a prototype.
> "parse1.cc", line 1406: Error: The function "free" must have a prototype.
> 4 Error(s) detected.
> *** Error code 2
> make: Fatal error: Command failed for target `parse1.o'

The explicit inclusion of  instead of  is made
because 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

bug#26738: Build failures

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> 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 distributed or not.
> If not here is a update for the test:
>
> diff --git a/t/check12.sh b/t/check12.sh
> index 34007896c..111f43318 100644
> --- a/t/check12.sh
> +++ b/t/check12.sh
> @@ -59,6 +59,7 @@ cat >> Makefile.am << 'END'
>  AUTOMAKE_OPTIONS += dejagnu
>  DEJATOOL = hammer spanner
>  AM_RUNTESTFLAGS = HAMMER=$(srcdir)/hammer SPANNER=$(srcdir)/spanner
> +EXTRA_DIST += $(DEJATOOL)
>  EXTRA_DIST += hammer.test/hammer.exp
>  EXTRA_DIST += spanner.test/spanner.exp
>  END

On second thought, I realize that distributing DEJATOOL automatically
would require handling ‘nodist_’ prefix in ‘automake’ since the content
of this variable could be generated scripts.  Given that this would
require a non negligeable amount of work, that seems more valuable to
require the package maintainers to add this variable to EXTRA_DIST
manually.

Let's apply this patch in a first step, and wait for a feature request
with a rationale before considering the other possibilty.

Commited in a0c7e40cf64d4512cc21ee5cdb9ba1341055f11c.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#26471: Automake 1.15 generates a recheck target that depends on all, breaking parallel builds

[Mathieu Lirzin]

Hi Seth,

Mathieu Lirzin <m...@gnu.org> writes:

> Seth Fowler <seth.fow...@me.com> 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
>> were dirty would cause random build failures. The symptom was that the
>> same file was getting built more than once by different make
>> processes, which led to the resulting objects being corrupted. We’d
>> see messages like this:
>>
>> libtool:   error: ‘foo.lo’ is not a valid libtool object
>>
>> I dug into this a little and the root cause of the problem seems to be
>> that unlike the other top-level targets generated by automake (check,
>> install, etc.), recheck depends on “all” instead of “all-am”. “all”
>> doesn’t declare very many dependencies - it just launches a new copy
>> of make that builds “all-am”. Because recheck also depends on other
>> targets (e.g. everything in check_PROGRAMS) which might depend on some
>> of the same things as “all-am”, in a parallel build the original make
>> process and the make process spawned by “all” can end up attempting to
>> build the same targets.
>>
>> I fixed this for our project by copying the generated recheck rule
>> into our Makefile.am and replacing “all” with “all-am”. After doing
>> this, I could no longer reproduce the problem with “make recheck -j8”.
>>
>> It seems like that change should be made in automake itself. Or maybe I just 
>> missed something - I’m far from an automake guru. =)
>
> Seems like a bug.

Any news?  Would be great if you could provide a way to reproduce this
issue.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#25335: automake - dejagnu RUNTESTDEFAULTFLAGS overrides AM_RUNTESTFLAGS

[Mathieu Lirzin]

Mathieu Lirzin <m...@gnu.org> writes:

> Carnë Draug <carandraug+...@gmail.com> writes:
>
>> There are 3 variables used by automake when calling dejagnu's
>> runtest:
>>
>>   $RUNTESTDEFAULTFLAGS - default from automake
>>   $AM_RUNTESTFLAGS - set by package developer
>>   $RUNTESTFLAGS - for user configuration
>>
>> However, AM_RUNTESTFLAGS is used first and is therefore overwritten
>> by RUNTESTDEFAULTFLAGS.  My use case is that I am not using recursive
>> make and therefore want to set dejagnu's srcdir to the testsuite
>> directory.  But RUNTESTDEFAULTFLAGS then sets it to $srcdir. Here's
>> the lines causing my issue:
>>
>> RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
>> [...]
>> if $(RUNTEST) $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS)
>> $(RUNTESTFLAGS); \
>> [...]
>>
>> A possible fix is to swap their order (simple patch attached).
>
> It seems like the right thing to do.  This has been fixed by commit
> 3126fa4c6b69c043e20af9381563069c0f2a0ba0
>
>> Another issue I am having with this is that the recipe to create the
>> site.exp file, also built by automake, sets dejagnu's srcdir to the
>> Makefile $srcdir again.  I am unsure how best to fix that (I guess a
>> maintainer variable).
>
> I am not sure to understand the issue correctly.  Can you try to explain
> it again?  I have no experience with DejaGNU, so don't hesitate to be
> explicit.

I am closing this since the main issue described was the order of
options.

Feel free to open a new bug if you want to report something about how
$(srcdir) is handled.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#29638: Same five tests fail with 1.15 on RHEL 7.4

[Mathieu Lirzin]

Hello,

Mathieu Lirzin <m...@gnu.org> writes:

> Dennis Clarke <dcla...@blastwave.org> 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 incomplete long option
>> FAIL: t/maken3.sh
>> FAIL: t/maken3-w.sh
>
> 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.

Here is a patch that should fix this issue.

>From 83d5d37bc8f0adb0e20a6fe7ab68029d2479dd32 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <m...@gnu.org>
Date: Thu, 18 Jan 2018 11:19:13 +0100
Subject: [PATCH] tests: Don't check 'Getopt::Long' corner cases

Depending on the installed 'Getopt::Long' perl module, command-line
handling may vary a bit.  As a consequence we prefer not to check
command-line corners cases.  This change fixes automake bug#29638.

* t/aclocal.sh (am_create_testdir): Don't expect "--versi" to be
interpreted as "--version".
* t/automake-cmdline.tap: Don't expect "--vers" to be interpreted as
"--version" and things after "--" to be interpreted as file arguments.
(do_check): Display the actual command output.
* t/maken3.sh (check_targets): "--force" is not a documented option, so
don't use it.
---
 t/aclocal.sh   |  2 --
 t/automake-cmdline.tap | 13 ++---
 t/maken3.sh|  2 +-
 3 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/t/aclocal.sh b/t/aclocal.sh
index 8cc8d5cc3..008493d5d 100644
--- a/t/aclocal.sh
+++ b/t/aclocal.sh
@@ -58,6 +58,4 @@ cat stderr >&2
 grep 'unrecognized option.*--ver' stderr
 grep '[Tt]ry.*--help.*for more information' stderr
 
-$ACLOCAL --versi
-
 :
diff --git a/t/automake-cmdline.tap b/t/automake-cmdline.tap
index c4441efe6..306231faa 100644
--- a/t/automake-cmdline.tap
+++ b/t/automake-cmdline.tap
@@ -18,7 +18,7 @@
 
 . test-init.sh
 
-plan_ 17
+plan_ 14
 
 # Usage: bad_cmdline DESCRIPTION REGEX-FOR-STDERR [ARGS-FOR-AUTOMAKE...]
 do_check ()
@@ -28,18 +28,11 @@ do_check ()
   regex=$1; shift
   AUTOMAKE_fails -d "$desc (run)" -- "$@"
   command_ok_ "$desc (stderr)" grep "$regex" stderr
+  cat stderr
 }
 
 do_check 'invalid long option' 'unrecognized option.*--voo' --voo
 
-# Older perl has a buggy Getopt::Long which makes this fail.
-if $PERL -e 'require 5.8.2;'; then
-  do_check "list of options terminated by '--'" \
-   'input file.*--voo' -- --voo
-else
-  skip_row_ 2 -r "older perl with buggy Getopt::Long"
-fi
-
 do_check "empty argument" \
  'empty argument' ''
 
@@ -58,6 +51,4 @@ do_check "'--help' as option argument" \
 do_check "ambiguous incomplete option" \
  'unrecognized option.*--ver' --ver
 
-command_ok_ "unambiguous incomplete long option" $AUTOMAKE --vers
-
 :
diff --git a/t/maken3.sh b/t/maken3.sh
index c37743cb7..8fe1d3269 100644
--- a/t/maken3.sh
+++ b/t/maken3.sh
@@ -181,7 +181,7 @@ check_targets || exit 1
 # TODO: add BUILT_SOURCES to sub2, fix fallout.
 sed 's/##//' < Makefile.am > t
 mv -f t Makefile.am
-$AUTOMAKE -Wno-override --force Makefile
+$AUTOMAKE -Wno-override Makefile
 ./configure
 check_targets || exit 1
 
-- 
2.15.1


Can you confirm this works on your system?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28967: How can I resolve this

[Mathieu Lirzin]

Hello,

Mathieu Lirzin <m...@gnu.org> writes:

> Sostom M N <sostomc...@gmail.com> 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 'Extending aclocal'
>> /usr/share/aclocal/log4c.m4:7: or see 
>> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
>> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of 
>> AM_PATH_LOG4C
>> /usr/share/aclocal/log4c.m4:7: run info Automake 'Extending aclocal'
>> /usr/share/aclocal/log4c.m4:7: or see 
>> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
>> automake: error: global options already processed
>> automake: Please contact <bug-automake@gnu.org>.
>> at /usr/share/automake-1.15/Automake/Channels.pm line 662,  line 105.
>> Automake::Channels::msg("automake", "", "global options already processed") 
>> called at /usr/share/automake-1.15/Automake/ChannelDefs.pm line 212
>> Automake::ChannelDefs::prog_error("global options already processed") called 
>> at /usr/share/automake-1.15/Automake/Options.pm line 421
>> Automake::Options::process_global_option_list(HASH(0x2f920b0)) called at 
>> /usr/bin/automake line 5337
>> Automake::scan_autoconf_traces("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
>
> I would need more context.  Could you give me some instructions to
> reproduce this bug?

Any news?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30127: ICC: 'entry point must be defined' error for shared builds on Windows

[Mathieu Lirzin]

date 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

bug#30128: MSVC: 'invalid numeric argument '/Wl, -DLL, -IMPLIB:.libs...' error for shared GMP builds on Windows

[Mathieu Lirzin]

m4' and update GMP build system. Then error
> not reproduced, and all build tasks finishes successfully.
>
> Can this patch be merged to Automake sources? Or it it possible to add
> '_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

bug#30126: Do not require “ltmain.sh” for out-of-tree libtool

[Mathieu Lirzin]

Hello Paolo,

Mathieu Lirzin <m...@gnu.org> writes:

>>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <bonz...@gnu.org>
> 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 see LT_SUPPORTED_TAG, it assumes an old libtool
> that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
> does not use Libtool's configure.ac macros this check gets a
> false positive.  Do not require ltmain.sh if no Libtool macro is
> found in configure.ac.
>
> * bin/automake.in ($libtool_bundled): New variable.
> (handle_libtool): Do not require libtool files if libtool is not being
> bundled.
> (scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
> ---

Would you have some time to allocate on a test for this patch in the
following days/weeks?  I would like to be able to merge it before
releasing Automake 1.16?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: bug#30126: Do not require “ltmain.sh” for out-of-tree libtool

[Mathieu Lirzin]

Hello Paolo,

Mathieu Lirzin <m...@gnu.org> writes:

>>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <bonz...@gnu.org>
> 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 see LT_SUPPORTED_TAG, it assumes an old libtool
> that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
> does not use Libtool's configure.ac macros this check gets a
> false positive.  Do not require ltmain.sh if no Libtool macro is
> found in configure.ac.
>
> * bin/automake.in ($libtool_bundled): New variable.
> (handle_libtool): Do not require libtool files if libtool is not being
> bundled.
> (scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
> ---

Would you have some time to allocate on a test for this patch in the
following days/weeks?  I would like to be able to merge it before
releasing Automake 1.16?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Do not require “ltmain.sh” for out-of-tree libtool

[Mathieu Lirzin]

I am opening a bug to keep track of this.

Mathieu Lirzin <m...@gnu.org> writes:

> Paolo Bonzini <bonz...@gnu.org> 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.  However, if the program
>>> does not use Libtool's configure.ac macros this check gets a
>>> false positive.  Do not require ltmain.sh if no Libtool macro is
>>> found in configure.ac.
>>> 
>>> Libtools that are not stone-age are already covered by LT_SUPPORTED_TAG
>>> and _LT_AC_TAGCONFIG, but add AC_PROG_LIBTOOL just in case for Libtool
>>> up to 1.4.
>>
>> This patch was never applied.
>>
>> Paolo
>>
>>> 2016-10-31  Paolo Bonzini  <bonz...@gnu.org>
>>> 
>>> * bin/automake.in ($libtool_bundled): New.
>>> (handle_libtool): Do not require libtool files if libtool is
>>> not being bundled.
>>> (scan_autoconf_traces): Set $libtool_bundled.  Trace
>>> AC_PROG_LIBTOOL too.
>>> 
>>> Signed-off-by: Paolo Bonzini <bonz...@gnu.org>
>>> ---
>>> If the patch is accepted I will send an Autoconf patch to
>>> preselect AC_PROG_LIBTOOL.
>>> 
>>> Since this is a bug, it would be nice to add it at least to
>>> the 1.16 branch.
>>> 
>>>  bin/automake.in | 12 +++-
>>>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> I haven't tested this, and I am not a Libtool expert so I trust your
> analysis.
>
> What do you think of adding a test ensuring that ltmain.sh is not
> required when no Libtool macro is found?
>
> I have attached a updated patch with trivial formatting and comment
> changes.

Here is the current version of the patch which needs a test to be
merged.

>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <bonz...@gnu.org>
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 see LT_SUPPORTED_TAG, it assumes an old libtool
that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
does not use Libtool's configure.ac macros this check gets a
false positive.  Do not require ltmain.sh if no Libtool macro is
found in configure.ac.

* bin/automake.in ($libtool_bundled): New variable.
(handle_libtool): Do not require libtool files if libtool is not being
bundled.
(scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
---
 bin/automake.in | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/bin/automake.in b/bin/automake.in
index 5e36c0f..b7fbe96 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -344,6 +344,8 @@ my @extra_recursive_targets = ();
 
 # Lists of tags supported by Libtool.
 my %libtool_tags = ();
+# 1 if Libtool is being bundled, so ltmain.sh is required.
+my $libtool_bundled = 0;
 # 1 if Libtool uses LT_SUPPORTED_TAG.  If it does, then it also
 # uses AC_REQUIRE_AUX_FILE.
 my $libtool_new_api = 0;
@@ -2524,7 +2526,7 @@ sub handle_libtool ()
   # (Starting with Libtool 2.0 we do not have to bother.  These
   # requirements are done with AC_REQUIRE_AUX_FILE.)
   require_conf_file_with_macro (TRUE, 'LIBTOOL', FOREIGN, @libtool_files)
-if $relative_dir eq '.' && ! $libtool_new_api;
+if $relative_dir eq '.' && $libtool_bundled && ! $libtool_new_api;
 
   my @libtool_rms;
   foreach my $item (sort keys %libtool_clean_directories)
@@ -5239,6 +5241,7 @@ sub scan_autoconf_traces
 		_AM_COND_IF => 1,
 		_AM_COND_ELSE => 1,
 		_AM_COND_ENDIF => 1,
+		AC_PROG_LIBTOOL => 0,
 		LT_SUPPORTED_TAG => 1,
 		_LT_AC_TAGCONFIG => 0,
 		m4_include => 1,
@@ -5482,10 +5485,17 @@ EOF
 		if $mtime > $configure_deps_greatest_timestamp;
 	}
 	}
+  elsif ($macro eq 'AC_PROG_LIBTOOL')
+	{
+	  # Detect bundling of really old Libtool up to 1.4 that does not
+	  # support tags.
+	  $libtool_bundled = 1;
+	}
   elsif ($macro eq 'LT_SUPPORTED_TAG')
 	{
 	  $libtool_tags{$args[1]} = 1;
 	  $libtool_new_api = 1;
+	  $libtool_bundled = 1;
 	}
   elsif ($macro eq '_LT_AC_TAGCONFIG')
 	{
@@ -5498,6 +5508,7 @@ EOF
 	  # Hardcode the tags supported by Libtool 1.5.
 	  %libtool_tags = (CC => 1, CXX => 1, GCJ => 1, F77 => 1);
 	}
+	  $libtool_bundled = 1;
 	}
 }
 
-- 
2.9.5


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#30126: Do not require “ltmain.sh” for out-of-tree libtool

[Mathieu Lirzin]

I am opening a bug to keep track of this.

Mathieu Lirzin <m...@gnu.org> writes:

> Paolo Bonzini <bonz...@gnu.org> 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.  However, if the program
>>> does not use Libtool's configure.ac macros this check gets a
>>> false positive.  Do not require ltmain.sh if no Libtool macro is
>>> found in configure.ac.
>>> 
>>> Libtools that are not stone-age are already covered by LT_SUPPORTED_TAG
>>> and _LT_AC_TAGCONFIG, but add AC_PROG_LIBTOOL just in case for Libtool
>>> up to 1.4.
>>
>> This patch was never applied.
>>
>> Paolo
>>
>>> 2016-10-31  Paolo Bonzini  <bonz...@gnu.org>
>>> 
>>> * bin/automake.in ($libtool_bundled): New.
>>> (handle_libtool): Do not require libtool files if libtool is
>>> not being bundled.
>>> (scan_autoconf_traces): Set $libtool_bundled.  Trace
>>> AC_PROG_LIBTOOL too.
>>> 
>>> Signed-off-by: Paolo Bonzini <bonz...@gnu.org>
>>> ---
>>> If the patch is accepted I will send an Autoconf patch to
>>> preselect AC_PROG_LIBTOOL.
>>> 
>>> Since this is a bug, it would be nice to add it at least to
>>> the 1.16 branch.
>>> 
>>>  bin/automake.in | 12 +++-
>>>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> I haven't tested this, and I am not a Libtool expert so I trust your
> analysis.
>
> What do you think of adding a test ensuring that ltmain.sh is not
> required when no Libtool macro is found?
>
> I have attached a updated patch with trivial formatting and comment
> changes.

Here is the current version of the patch which needs a test to be
merged.

>From a936b7d4cf8583ace0be6756b4b066a2c1aebe18 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <bonz...@gnu.org>
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 see LT_SUPPORTED_TAG, it assumes an old libtool
that does not know about AC_REQUIRE_AUX_FILE.  However, if the program
does not use Libtool's configure.ac macros this check gets a
false positive.  Do not require ltmain.sh if no Libtool macro is
found in configure.ac.

* bin/automake.in ($libtool_bundled): New variable.
(handle_libtool): Do not require libtool files if libtool is not being
bundled.
(scan_autoconf_traces): Set $libtool_bundled.  Trace AC_PROG_LIBTOOL.
---
 bin/automake.in | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/bin/automake.in b/bin/automake.in
index 5e36c0f..b7fbe96 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -344,6 +344,8 @@ my @extra_recursive_targets = ();
 
 # Lists of tags supported by Libtool.
 my %libtool_tags = ();
+# 1 if Libtool is being bundled, so ltmain.sh is required.
+my $libtool_bundled = 0;
 # 1 if Libtool uses LT_SUPPORTED_TAG.  If it does, then it also
 # uses AC_REQUIRE_AUX_FILE.
 my $libtool_new_api = 0;
@@ -2524,7 +2526,7 @@ sub handle_libtool ()
   # (Starting with Libtool 2.0 we do not have to bother.  These
   # requirements are done with AC_REQUIRE_AUX_FILE.)
   require_conf_file_with_macro (TRUE, 'LIBTOOL', FOREIGN, @libtool_files)
-if $relative_dir eq '.' && ! $libtool_new_api;
+if $relative_dir eq '.' && $libtool_bundled && ! $libtool_new_api;
 
   my @libtool_rms;
   foreach my $item (sort keys %libtool_clean_directories)
@@ -5239,6 +5241,7 @@ sub scan_autoconf_traces
 		_AM_COND_IF => 1,
 		_AM_COND_ELSE => 1,
 		_AM_COND_ENDIF => 1,
+		AC_PROG_LIBTOOL => 0,
 		LT_SUPPORTED_TAG => 1,
 		_LT_AC_TAGCONFIG => 0,
 		m4_include => 1,
@@ -5482,10 +5485,17 @@ EOF
 		if $mtime > $configure_deps_greatest_timestamp;
 	}
 	}
+  elsif ($macro eq 'AC_PROG_LIBTOOL')
+	{
+	  # Detect bundling of really old Libtool up to 1.4 that does not
+	  # support tags.
+	  $libtool_bundled = 1;
+	}
   elsif ($macro eq 'LT_SUPPORTED_TAG')
 	{
 	  $libtool_tags{$args[1]} = 1;
 	  $libtool_new_api = 1;
+	  $libtool_bundled = 1;
 	}
   elsif ($macro eq '_LT_AC_TAGCONFIG')
 	{
@@ -5498,6 +5508,7 @@ EOF
 	  # Hardcode the tags supported by Libtool 1.5.
 	  %libtool_tags = (CC => 1, CXX => 1, GCJ => 1, F77 => 1);
 	}
+	  $libtool_bundled = 1;
 	}
 }
 
-- 
2.9.5


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [PATCH] automake: Add default libtool_tag to cppasm.

[Mathieu Lirzin]

Hello,

Khem Raj <raj.k...@gmail.com> writes:

> * bin/automake.in (register_language): Define default libtool tag to be CC
> since CPPASCOMPILE is using CC to call assembler
>
> Signed-off-by: Khem Raj <raj.k...@gmail.com>
> ---

Pushed as commit dc67b18d6648899ee284b66ca1529c47495672ea.

Thanks for your contribution and sorry for the delay.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#29376: automake gnits version check vs. gnulib's git-version-gen?

[Mathieu Lirzin]

Paul Eggert <egg...@cs.ucla.edu> writes:

> On 11/20/2017 11:44 PM, Bernhard Voelker wrote:
>> So my question: aren't 3-level version strings allowed by the gnits check
>> in combination with gnulib's git-version-gen script?  Do we have to
>> change
>> the strictness from gnits to gnu?
>
> I would think so, unless someone takes the time to change Automake so
> that gnits supports the new format of version strings that
> git-version-gen is generating.

Such change would be welcome.

Basically one would have to adapt the following regexp from automake.

--8<---cut here---start->8---
# This pattern recognizes a Gnits version id and sets $1 if the
# release is an alpha release.  We also allow a suffix which can be
# used to extend the version number with a "fork" identifier.
my $GNITS_VERSION_PATTERN = '\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

bug#29638: Same five tests fail with 1.15 on RHEL 7.4

[Mathieu Lirzin]

Eric Blake <ebl...@redhat.com> 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/wrap/automake-1.15 --vers
>> automake (GNU automake) 1.15.1
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv2+: GNU GPL version 2 or later 
>> <http://gnu.org/licenses/gpl-2.0.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> 
>> Written by Tom Tromey <tro...@redhat.com>
>>and Alexandre Duret-Lutz <a...@gnu.org>.
>> --8<---cut here---end--->8---
>> 
>> According to your logs this doesn'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?
>
> If I understand GNU Coding Standards, we really do want to make sure
> unambiguous abbreviations of long options work.  

I am unaware of such GCS recommandation.  Do you have a pointer to the
part of the standards suggesting that?

> I'd argue that if not all versions of perl Getopt::Long are working
> the way the testsuite currently expects, that we should instead keep
> the test unchanged and find ways to work around the broken perl module
> versions (perhaps by manually specifying all abbreviations as explicit
> options ourselves, rather than relying on Getopt::Long to do it for
> us).

This could indeed be done, however I am not convinced by the usefulness
of such workaround.

> At the same time, once we do ascertain which version of
> Getopt::Long you are using, it may be worth reporting the flaw in that
> version to your distro vendor, as Automake is not the only software
> that would have to work around that particular weakness.

Agreed.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#29188: Test suite failures on macOS High Sierra 10.13

[Mathieu Lirzin]

Hello,

Barry Anderson <z3ndra...@me.com> writes:

> FAIL: t/distcheck-override-infodir
> ==
>
> distcheck-override-infodir: running makeinfo --version
> makeinfo (GNU texinfo) 4.8

All the build failures are related to the same issue caused by some
command line handling from this old 'texi2dvi' script (released in 2005)

> make[1]: Nothing to be done for `all'.
> TEXINPUTS="../..:$TEXINPUTS" \
>   MAKEINFO='/bin/sh 
> /Users/bwa/Downloads/automake-1.15.1/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/missing
>  makeinfo   -I ../..' \
>   texi2dvi  --build-dir=main.t2d -o main.dvi  \
>   ../../main.texi
> /usr/bin/texi2dvi: Can't use option `--output' with more than one argument.

Since the behavior has been fixed in more recent texinfo releases, I am
not sure 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

bug#23742: [PROPOSED PATCH] vala: add support for Genie .gs files

[Mathieu Lirzin]

Hello Chris,

Mathieu Lirzin <m...@gnu.org> writes:

> Chris Daley <chebiza...@gmail.com> 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 command
>> line.
>>
>> https://wiki.gnome.org/Projects/Genie
>>
>> Automake does not currently support files with the extension .gs - this is 
>> easily confirmed by adding one to the _SOURCE primary for a Vala project.
>>
>> This patch adds support for Genie files. The patch includes
>> modifications to the existing Vala tests to 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 install it in Automake?

Any news regarding the copyright assignment?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#29638: Same five tests fail with 1.15 on RHEL 7.4

[Mathieu Lirzin]

Hello,

Dennis Clarke <dcla...@blastwave.org> writes:

> The same five tests fail for automake 1.15 and 1.15.1 on RHEL 7.4. Also
> the testsuite itself reports mysterious "Error 1" and "Error 2" upon
> termination and that looks questionable :
>
> 
> Testsuite summary for GNU Automake 1.15
> 
> # TOTAL: 2693
> # PASS:  2422
> # SKIP:  226
> # XFAIL: 40
> # FAIL:  5
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to bug-automake@gnu.org
> 
> gmake[2]: *** [Makefile:3027: test-suite.log] Error 1
> gmake[2]: Leaving directory
> '/usr/local/build/automake-1.15_3.10.0-693.11.1.el7.x86_64.001'
> gmake[1]: *** [Makefile:3135: check-TESTS] Error 2
> gmake[1]: Leaving directory
> '/usr/local/build/automake-1.15_3.10.0-693.11.1.el7.x86_64.001'
> gmake: *** [Makefile:3366: check-am] Error 2
> admsys@sedna$
>
>
> 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 incomplete long option
> FAIL: t/maken3.sh
> FAIL: t/maken3-w.sh

The common characteristic of those failures is the command line
handling.

Automake use Perl provided Getopt::Long module to parse the command line
arguments and the version you are using seems to behave differently than
usual.

for example from Automake 1.15.1 build directory the following command
is supposed to work:

--8<---cut here---start->8---
$ t/wrap/automake-1.15 --vers
automake (GNU automake) 1.15.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 
<http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tro...@redhat.com>
   and Alexandre Duret-Lutz <a...@gnu.org>.
--8<---cut here---end--->8---

According to your logs this doesn'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

bug#29178: Failure to build automake > 11

[Mathieu Lirzin]

Hello,

carl hansen <carlhansen1...@gmail.com> writes:

>>
>> Ah, that looks like it could be the culprit:
>>
>> ig25@linux-d6cw:~/Downloads/automake-1.15> t/wrap/automake-1.15 --help
>> Unescaped left brace in regex is illegal here in regex; marked by <-- HERE
>> in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at
>> /home/ig25/Downloads/automake-1.15/bin/automake line 3936.
>> Compilation failed in require at t/wrap/automake-1.15 line 27.
>>
>>
> That's fixed in automake 1.15.1 you seem to be using 1.15

I assume that this was the actual problem.  Since 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

Re: Document the portability of various tar formats better

[Mathieu Lirzin]

Hi,

Bruno Haible <br...@clisp.org> writes:

> While running the (automake-provided) 'dist' target of GNU gettext, I
> encountered this error:
>
> tar: 
> gettext-0.19.8.1.74-72e49-dirty/gettext-tools/gnulib-tests/test-term-ostream-xterm-linux-mandriva.out:
>  file name is too long (max 99); not dumped
> tar: 
> gettext-0.19.8.1.74-72e49-dirty/gettext-runtime/intl-csharp/doc/GNU_Gettext_GettextResourceManager.html:
>  file name is too long (max 99); not dumped
>
> My findings [1] confirm the description of the 'tar-ustar' and 'tar-pax'
> option. However, I found the text
>   "... is believed to be old enough ..."
>   "... very modern platforms"
> a bit vague to base decisions on. Therefore here is a documentation patch
> to document the actual findings.

Indeed more precision is better in this context.

> [1] https://savannah.gnu.org/support/index.php?109437
>
> From 7ba5050bd7a40d467378bad642ec1e11ca85df96 Mon Sep 17 00:00:00 2001
> From: Bruno Haible <br...@clisp.org>
> Date: Wed, 3 Jan 2018 01:52:34 +0100
> Subject: [PATCH] doc: Document the portability of various tar formats better.
>
> * doc/automake.texi (List of Automake options): Document the portability of
> the tar-ustar and tar-pax options better.
> ---

Pushed in commit fab4fb3aabf0a20d4c99fb7171de163d42e391e2.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37