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

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

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

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

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

[Mathieu Lirzin]

Hello,

"George Gaarder"  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: [GSOC] Proposal for "Modularize Automake to improve the test-suite performance"

[Mathieu Lirzin]

Hello,

Matthias Paulmier  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  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  and
drop  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  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  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  writes:

> Mathieu Lirzin  writes:
>
>> Matthias Paulmier  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  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  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

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

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

[Mathieu Lirzin]

Hello Matthias,

Matthias Paulmier  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  writes:

> On Mar 7, 2018 16:05, "Mathieu Lirzin"  wrote:
>
>  John Calcote  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  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  writes:

> On Tue, Feb 27, 2018 at 9:07 PM, Adam Mercer  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

Re: GNU Automake 1.16 released

[Mathieu Lirzin]

Hello,

Eric Dorland  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: Automake 1.16 build failure

[Mathieu Lirzin]

Hello,

Andreas Schwab  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  for this issue?

Thanks.

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

>>>>>> "Jonas" == Jonas Thiem  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
semantics of how config.status bootstraps

Re: Ideas for Summer of Code 2018

[Mathieu Lirzin]

Mathieu Lirzin  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: Why doesn't install-strip strip shared libraries sometimes

[Mathieu Lirzin]

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

Ideas for Summer of Code 2018

[Mathieu Lirzin]

Hello,

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.

I plan to propose the following project:

Modularize Automake to improve the test-suite performance

   Currently automake is implemented as a monolithic Perl script with some
   modules for code shared with aclocal which is another script
   distributed with Automake. To ensure its practical correctness Automake
   provides a huge test-suite and requires every non-trivial bug-fix to be
   covered by an additional non-regression test. Unfortunately this whole
   test-suite is quite slow to run (~20-30 min) which makes it hard for
   maintainers to effectively use it, and is long enough to refrain users
   to run it. The main reason for this slowness is that almost all tests
   are integration/validation tests that touch the file system. A more
   effective approach would be to replace those with unit tests when
   possible. The objective of this project is to incrementally refactor
   the current implementation by decomposing it into modules and unit test
   those with [1]Test::More.

   Skills: Good understanding of the different testing strategies, Basic
   knowledge of Perl
   Mentor: Mathieu Lirzin

References

   1. https://perldoc.perl.org/Test/More.html

Comments and suggestions welcome.

If you want to propose another project that you are willing to mentor,
feel free to share your ideas on this list too.  The deadline for
submitting a project is the beginning of March.

[1] https://summerofcode.withgoogle.com/

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

Re: Which component controls automake.info ?

[Mathieu Lirzin]

Jeffrey Walton  writes:

> On Thu, Jan 4, 2018 at 7:45 AM, Mathieu Lirzin  wrote:
>> Hello,
>>
>> Jeffrey Walton  writes:
>>
>>> On Wed, Jan 3, 2018 at 10:00 AM, Mathieu Lirzin  wrote:
>>>>
>>>> Jeffrey Walton  writes:
>>>>
>>>>> I'm trying to update Autoconf and Automake on an old CentOS system.
>>>>> The build is failing with:
>>>>>
>>>>>   MAKEINFO doc/automake.info
>>>>> /home/scripts/automake-1.15.1/lib/missing: line 81: makeinfo: command not 
>>>>> found
>>>>> ...
>>>> Documentation is already "built" in distributed releases so unless you
>>>> are modifying the ".texi" sources, 'makeinfo' shouldn't be required by
>>>> the build process.
>>>
>>> Maybe autoreconf is doing it. I need to use it on a lot of older
>>> systems, like CentOS 5 or my PowerMac G5.
>>>
>>> I use the old iron for testing. Most of the software is out of date.
>>>
>>>> Are you build from a tarball or the Git development repository?
>>>
>>> I'm using the latest release tarball. It is
>>> https://ftp.gnu.org/gnu/automake/automake-1.15.1.tar.gz
>>
>> Indeed the 'autoreconf' step might be the issue.  When building from a
>> release tarball the build/install process should only be "./configure &&
>> make && make install".  See the INSTALL file for more detailed
>> information.
>
> This worked well. It was run after configure.
>
> sed -e 's|^MAKEINFO =*|MAKEINFO = true|g' Makefile > Makefile.fixed
> mv Makefile.fixed Makefile

OK.  Can you confirm that the following commands works on your system
without requiring 'makeinfo'?

   $ wget https://ftp.gnu.org/gnu/automake/automake-1.15.1.tar.gz
   $ tar xzf automake-1.15.1.tar.gz
   $ cd automake-1.15.1
   $ ./configure
   $ make

Otherwise it is a bug.

Thanks.

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

Re: Which component controls automake.info ?

[Mathieu Lirzin]

Hello,

Jeffrey Walton  writes:

> On Wed, Jan 3, 2018 at 10:00 AM, Mathieu Lirzin  wrote:
>>
>> Jeffrey Walton  writes:
>>
>>> I'm trying to update Autoconf and Automake on an old CentOS system.
>>> The build is failing with:
>>>
>>>   MAKEINFO doc/automake.info
>>> /home/scripts/automake-1.15.1/lib/missing: line 81: makeinfo: command not 
>>> found
>>> ...
>> Documentation is already "built" in distributed releases so unless you
>> are modifying the ".texi" sources, 'makeinfo' shouldn't be required by
>> the build process.
>
> Maybe autoreconf is doing it. I need to use it on a lot of older
> systems, like CentOS 5 or my PowerMac G5.
>
> I use the old iron for testing. Most of the software is out of date.
>
>> Are you build from a tarball or the Git development repository?
>
> I'm using the latest release tarball. It is
> https://ftp.gnu.org/gnu/automake/automake-1.15.1.tar.gz

Indeed the 'autoreconf' step might be the issue.  When building from a
release tarball the build/install process should only be "./configure &&
make && make install".  See the INSTALL file for more detailed
information.

The 'autoreconf' step is meant for developers and maintainers building
from the Git repository.  This step generates (among other things) the
"./configure" shell script that is then distributed in tarballs.  This
staged build process allows to separate developer dependencies
(Autoconf, Automake, Makeinfo, Help2man, ...) from regular dependency.

HTH.

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

Re: Which component controls automake.info ?

[Mathieu Lirzin]

Hello,

Jeffrey Walton  writes:

> I'm trying to update Autoconf and Automake on an old CentOS system.
> The build is failing with:
>
>   MAKEINFO doc/automake.info
> /home/scripts/automake-1.15.1/lib/missing: line 81: makeinfo: command not 
> found
> WARNING: 'makeinfo' is missing on your system.
>  You should only need it if you modified a '.texi' file, or
>  any other file indirectly affecting the aspect of the manual.
>  You might want to install the Texinfo package:
>  <http://www.gnu.org/software/texinfo/>
>  The spurious makeinfo call might also be the consequence of
>  using a buggy 'make' (AIX, DU, IRIX), in which case you might
>  want to install GNU make:
>  <http://www.gnu.org/software/make/>
> gmake: *** [Makefile:2518: doc/automake.info] Error 127
>
> According to ./configure --help, I can disable it with
> --disable-FEATURE. The problem I am having is, I don't know what the
> feature's name is.
>
> I tried the obvious ones, like --disable-docs and --disable--texi.
>
> What is the feature name of the documentation so I can disable it?
>
> (It also seems like a bad idea to fail a build for a feature I don't
> want. Maybe it would be more prudent to print a warning message
> instead of failing the primary task).

Documentation is not considered as a "feature" in that sense.

Documentation is already "built" in distributed releases so unless you
are modifying the ".texi" sources, 'makeinfo' shouldn't be required by
the build process.

Are you build from a tarball or the Git development repository?

Thanks.

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

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Mathieu Lirzin]

Jim Meyering  writes:

> On Mon, Nov 27, 2017 at 8:12 PM, Jim Meyering  wrote:
>> On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering  wrote:
>>> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris  wrote:
>>>>
>>>> In general, Emacs expects .el and .elc to be found in the same
>>>> directory. Not adhering to this convention will likely break various
>>>> Emacs features. Is this really something automake needs to enable at all?
>>>
>>> An alternative would be to copy-or-link the .el file into the
>>> destination directory. Indeed. That would work without breaking pre-23
>>> emacs, so I will adjust my automake patch before pushing it to master.
>>
>> Hi Glenn,
>>
>> I've thought about this some more and do not like the idea of
>> requiring automake's elisp-compilation rule to make a copy of the
>> source file in the destination directory in this slightly contrived
>> case. Remember: this arises only in a non-srcdir build. That means
>> build artifacts end up being written into the mostly-empty current
>> directory hierarchy, which does not have copies of the sources.
>> Installation processes will continue to copy both .el and .elc files
>> into place.

I don't like this idea neither.

> Here is the updated (NEWS addition) patch that I expect to push to
> master tomorrow. Feedback welcome. I will also delete the "micro"
> branch I created.

> From 7558bddcc9cf5ee14441304c2cfc7cffb566daba Mon Sep 17 00:00:00 2001
> From: Jim Meyering 
> Date: Wed, 22 Nov 2017 21:07:29 -0800
> Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer
>
> In May of 2017, Emacs' support for using the long-deprecated
> byte-compile-dest-file function was removed, and that removal broke
> automake's elisp-compiling rule for any .el file not in the current
> directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
> became the recommended way to adjust the byte-compiler's destination.
> We expect the removed functionality to be restored for Emacs-26,
> albeit with dissuasive diagnostics warning about the imminent removal
> of this functionality.  It may be removed in Emacs-27.
> * lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
> rather than byte-compile-dest-file.
> * t/lisp-readonly-srcdir.sh: New file, to test for the above.
> * t/list-of-tests.mk (handwritten_TESTS): Add it.
> * NEWS (Bugs fixed): Mention this problem.

OK to push.

Thanks.

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

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

[Mathieu Lirzin]

Hello Jim,

Jim Meyering  writes:

> I was dismayed to discover this patch I wrote over three years ago.
> Today I confirmed that the problem still remains by running these commands:
>
>   git clone git://git.sv.gnu.org/hello.git \
> cd hello && ./bootstrap && ./configure && env make dist
>
> It failed like this:
>
>   src/hello.c:27:10: fatal error: configmake.h: No such file or directory
>#include "configmake.h"
> ^~
>
> Here's the patch I expect to push to master:
>
> From: Jim Meyering 
> Date: Thu, 20 Mar 2014 12:31:32 -0700
> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)
>
> * lib/am/distdir.am (distdir-am): New intermediate target.
> Interpose this target between $(distdir) and its dependency
> on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
> all created before we begin creating $(DISTFILES).
> * t/dist-vs-built-sources.sh: Test for this.
> * t/list-of-tests.mk (handwritten_TESTS): Add it.
> * NEWS (Bugs fixed): Mention it.
> Assaf Gordon reported that "make dist" (after ./configure
> from a pristine clone of GNU hello) would fail due to the
> absence of configmake.h while compiling lib/localcharset.c.
> https://lists.gnu.org/r/bug-hello/2014-03/msg00016.html
> ---
>  NEWS   |  3 +++
>  lib/am/distdir.am  |  7 --
>  t/dist-vs-built-sources.sh | 56 
> ++
>  t/list-of-tests.mk |  1 +
>  4 files changed, 65 insertions(+), 2 deletions(-)
>  create mode 100644 t/dist-vs-built-sources.sh

OK to push.

Thanks.

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

Update HACKING (was: [PATCH] port elisp-compilation support to emacs-23.1 and newer)

[Mathieu Lirzin]

Mathieu Lirzin  writes:

> Indeed HACKING is not up-to-date, I will fix that.

Here is a patch that should help describing the new branching model more
accurately.  If you see further improvements or would prefer different
wording, tell me.

>From 2e6c978a944eb57d49336b01a03dd6f9e573cd81 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Fri, 24 Nov 2017 13:28:24 +0100
Subject: [PATCH] maint: Update HACKING

* HACKING (Working with git): Remove reference to the 'micro' branch and
adapt branch descriptions to the current branching scheme.
---
 HACKING | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/HACKING b/HACKING
index 8e7764b..ded1c7f 100644
--- a/HACKING
+++ b/HACKING
@@ -156,15 +156,8 @@
   latest stable version of Autoconf installed and available early
   in your PATH.
 
-* The Automake git tree currently carries three basic branches: 'micro',
-  'maint' and 'master'.
-
-* The 'maint' branch, reserved to changes that should go into the next
-  micro release; so it will just see fixes for regressions, trivial
-  bugs, or documentation issues, and no "active" development whatsoever.
-  Since emergency regression-fixing or security releases could be cut
-  from this branch at any time, it should always be kept in a releasable
-  state.
+* The Automake git tree currently carries three basic branches: 'master',
+  'next' and 'maint'.
 
 * The 'master' branch is where the development of the next release
   takes place.  It should be kept in a stable, almost-releasable state,
@@ -172,6 +165,16 @@
   this is not a hard rule, and such "stability" is not expected to be
   absolute (emergency releases are cut from the 'maint' branch anyway).
 
+* When planning a release a dedicated branch should be created and after
+  the release is done, the release branch is to be merged both into the
+  'master' branch and the 'maint' branch.
+
+* Besides merges from release branches, the 'maint' branch can contain
+  fixes for regressions, trivial bugs, or documentation issues, that
+  will be part of an emergency regression-fixing or security releases.
+  As a consequence it should always be kept in a releasable state and no
+  "active" development should be done whatsoever.
+
 * The 'next' branch is reserved for the development of the next major
   release.  Experimenting a little is OK here, but don't let the branch
   grow too unstable; if you need to do exploratory programming or
@@ -187,15 +190,6 @@
   developments.  They should be based off of a common ancestor of all
   active branches to which the feature should or might be merged later.
 
-* After a release is done, the release branch is to be merged both
-  into the 'master' branch and the 'maint' branch.
-
-* When fixing a bug (especially a long-standing one), it may be useful
-  to commit the fix to a new temporary branch based off the commit that
-  introduced the bug.  Then this "bugfix branch" can be merged into all
-  the active branches descending from the buggy commit.  This offers a
-  simple way to fix the bug consistently and effectively.
-
 * When merging, prefer 'git merge --log' over plain 'git merge', so that
   a later 'git log' gives an indication of which actual patches were
   merged even when they don't appear early in the list.
-- 
2.9.5


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

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Mathieu Lirzin]

Jim Meyering  writes:

> On Thu, Nov 23, 2017 at 3:57 PM, Mathieu Lirzin  wrote:
>>
>> Jim Meyering  writes:
>>
>>> Pushed to the micro branch:
>>>
>>> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro&id=9182df7e4810a411147d523de8cd141e749c5e39
>>
>> With the "recent" change in Automake branch naming scheme, 'master'
>> seems a better fit for this:
>>
>>   https://lists.gnu.org/archive/html/bug-automake/2017-09/msg00015.html
>>
>> Thanks.
>
> Hi Mathieu,
> Happy to adjust. Would you prefer that I merge micro into master,
> then... or something else? Then delete micro? When I noticed that I'd
> created that branch (after reading the description in HACKING), I
> figured I'd missed something.

Indeed HACKING is not up-to-date, I will fix that.

Cherry-picking the commit and deleting 'micro' would be nice.  Moreover
I think it worths adding a NEWS entry for this bug fix, if you agree
please add it.  :-)

The fix will be released in 1.16.  I was planning to make this release
by the end of the year, but given that I am quite busy at the university
I think i won't be able to make it before January/February.

Thanks for fixing this issue.

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

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Mathieu Lirzin]

Hello Jim,

Jim Meyering  writes:

> On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering  wrote:
>> I wanted to make a new idutils release, but was blocked because
>> its "make distcheck" would fail. That was because it distributes
>> and builds from an elisp file, and automake's elisp-compilation
>> rule uses a function that was marked obsolete back in 2009.
>> Upstream Emacs finally removed support for that function in May,
>> so anyone using emacs built since then will see the same failure
>> I saw. It also strikes whenever building from a read-only source
>> directory.
>>
>> This change switches the build command to use the "new" way.
>>
>> I started discussion on emacs-devel last night:
>> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>>
>>
>> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering 
>> Date: Wed, 22 Nov 2017 21:07:29 -0800
>> Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer
>>
>> In May of 2017, support for using the long-deprecated
>> byte-compile-dest-file function was removed, and that removal broke
>> automake's elisp-compiling rule for any .el file not in the current
>> directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
>> became the recommended way to adjust the byte-compiler's destination.
>> * lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
>> rather than byte-compile-dest-file.
>> * t/lisp-readonly-srcdir.sh: New file, to test for the above.
>> * t/list-of-tests.mk (handwritten_TESTS): Add it.
>
> Pushed to the micro branch:
>
> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro&id=9182df7e4810a411147d523de8cd141e749c5e39

With the "recent" change in Automake branch naming scheme, 'master'
seems a better fit for this:

  https://lists.gnu.org/archive/html/bug-automake/2017-09/msg00015.html

Thanks.

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

Re: Per-Object Flags for Autotool C++ library?

[Mathieu Lirzin]

Hello Jeffrey,

Jeffrey Walton  writes:

> On Sat, Nov 4, 2017 at 5:00 PM, Nick Bowler  wrote:
>> On 11/4/17, Jeffrey Walton  wrote:
>>> ...
>>> One of our driving principles is "things just work". We don't want
>>> library users inconvenienced or installing extra software. They should
>>> be able to sit down at their computer, run configure, and everything
>>> should work as expected.
>>>
>>> If something does not work as expected then it becomes our problem.
>>> We are expected to find workarounds so library users are not
>>> inconvenienced.
>>
>> Library users shouldn't be running Automake at all, because when you
>> distribute a package all of the generated files are included (and do
>> not depend on Automake).
>>
>> e.g., if you create your package with the latest versions then it
>> should "just work" on Solaris.
>
> Thanks. If you come across the docs on how to do it, then please pass it on :)
>
> Here's the closest I have found:
> https://www.gnu.org/software/automake/manual/html_node/Basics-of-Distribution.html.
> But it lacks a list of actionable items, so I only have part of the
> picture. I don't have the experience to make the leap to what actually
> needs to be done. No one with the project has the experience, either.

This is the correct pointer.

The idea behind the Autotools is to not add extra dependency to the
build system for users building from source.  As a consequence
maintainers when doing a release generates a tarball with "make dist"
that already contains the configure, Makefile.in which are generated by
Autoconf and Automake.

What needs to be done is to check that everything that is needed by
the build system is included in the tarball generated by 'make dist'.
This can be done manually by trying to build from that tarball or
alternatively 'make distcheck' verifies that automatically among other
important things (out of tree builds, uninstall, ...).

The first actionable item it to check that the build from the tarball
works fine, and if not add the missing files to the EXTRA_DIST variable
(or alternatives) in the Makefile.am.

'make distcheck' error message can sometime be tricky to interpret, so
feel free to ask for help.

HTH.

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

Re: libcpu_a_CXXFLAGS must be set with '=' before using '+='

[Mathieu Lirzin]

Jeffrey Walton  writes:

> This is related to Nick and Mathieu's comments about per-object flags
> and use of CXXFLAGS.
>
> When I change the pattern to:
>
>   CPU_FLAG = -msse2
>   libcpu_a_SOURCES = cpu.cpp
>   libcpu_a_CXXFLAGS += $(CPU_FLAG)
>
> I encounter:
>
>   Makefile.am:64: error: libcpu_a_CXXFLAGS must be set with '=' before
> using '+='
>
> I think there are two or three issues with what I am trying to do, and
> the issue with "+=" is only the most prominent symptom.
>
> I think this document may be controlling:
> https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html#Flag-Variables-Ordering.
> The paragraph that starts with "What we recommend is that you define
> extra flags in separate variables" is especially interesting to
> me. It is interesting because `CPU_FLAG` will eventually need to be
> computed based on the platform. (Eventually we need: i386 gets -msse2;
> x86_64 gets nothing; ARMv7 gets NEON; and PowerPC gets Power4 and
> Altivec; others get nothing).
>
> Please forgive my ignorance, but how do I fix this issue such that it
> won't break when I start computing the value of CPU_FLAG in Autoconf?

Maybe I am overlooking something but using '=' shouldn't cause any issue
event if CPU_FLAG is computed from Autoconf.

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

Re: Per-Object Flags for Autotool C++ library?

[Mathieu Lirzin]

Hello,

Nick Bowler  writes:
>
> On 11/2/17, Jeffrey Walton  wrote:
>>
>> CPU_FLAG = -msse2 -msse3 -mssse3
>> libcpu_a_SOURCES = cpu.cpp
>> libcpu_a_CXXFLAGS = $(CXXFLAGS) $(CPU_FLAG)
>
> Note that you should not include $(CXXFLAGS) here.  CXXFLAGS is always
> included (so with this it will duplicated on the command line, which
> might be undesired by the user).

I guess Jeffrey was intending to use AM_CXXFLAGS which is overridden by
libcpu_a_CXXFLAGS.

>> Now that the objects are built we need to add libcpu.a back into
>> libcryptopp.la in the exact position it would have been in if I could
>> have specified per-object flags. The Automake manual gives an example
>> of linking a program with disjoint libraries, but not adding the
>> extraneous library back to the main (primary?) library at a particular
>> position.
>>
>> The "in the exact position" is important.

I don't fully understand the "static initialization fiasco", however the
next entry in the FAQ [1] seems to suggest that it can be avoided
programmatically using a function wrapper instead of relying on the
linking order.

If this kind of issue is common in C++, I think it would be good to
give a hint in the Automake manual on how to solve it.

Thanks.

[1] https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use

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

Re: Should Automake still support Java?

[Mathieu Lirzin]

Hello,

NightStrike  writes:

> On Mon, Oct 30, 2017 at 12:09 PM, Mathieu Lirzin  wrote:
>
>> - Should we undeprecate javac support?
>
> Undeprecate, please.
>
> I use automake's java support quite a bit, as I have numerous projects
> that are mostly other languages, but that include some java utilities.
> It is very nice to manage everything from a single autoconf / automake
> setup.  In fact, we picked automake exactly because it supported every
> required language.
>
> Please do not remove this support.

   I haven't investigated the reason why the javac support has been
deprecated in the first place, the manual says that the interface is not
clean/good enough:

--8<---cut here---start->8---
Automake provides some minimal support for Java bytecode compilation
with the ‘JAVA’ primary (in addition to the support for compiling Java
to native machine code; *note *Java Support with gcj*).  Note however
that _the interface and most features described here are deprecated_.
Future Automake releases will strive to provide a better and cleaner
interface, which however _won’t be backward-compatible_; the present
interface will probably be removed altogether some time after the
introduction of the new interface (if that ever materializes).  In any
case, the current ‘JAVA’ primary features are frozen and will no longer
be developed, not even to take bug fixes.
--8<---cut here---end--->8---

   For example it doesn't seem to support creating jar files.  Maybe you
could provide some feedback about your experience with this interface?
Have you faced any particular issues?  How have you handled them?

   Instead of unndeprecating this interface, we could provide an example
snippet in the manual that would help transition out of it by replacing
the usage of _JAVA with _DATA.  Something like:

--8<---cut here---start->8---
javadir = $(datadir)/java
java_DATA = foo.jar

foo.jar: $(java_sources:.java=.class)
jar ...

java_sources = A.java B.java

.java.class:
javac ...

EXTRA_DIST = $(java_sources)
--8<-------cut here---end--->8---

WDYT?

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

Should Automake still support Java?

[Mathieu Lirzin]

Hello,

   Currently Automake supports two ways of compiling Java code.  One is
with the 'javac' compiler which is deprecated on the Automake side, and
the other (the recommanded one) which uses GCJ.  Relying on GCJ feels
outdated since GCJ has been removed from GCC since version 7 and is not
distributed on recent Debian/Fedora/Ubuntu distributions anymore.

   As a consequence, I am considering removing Java support.  Before
doing that, I would like to consult others, particularly people who may
still rely on those features.  My questions are the followings:

- Should we remove GCJ support?
- Should we remove javac support?
- Should we undeprecate javac support?
- When should it be done (1.16/1.17/...) ?

   If some of you have still access to GCJ, I would be grateful if they
could help with bug#24895 [1] which can't be adressed otherwise.

Thanks.

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

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

Re: Like config.h.in but in Ada

[Mathieu Lirzin]

Victor Porton  writes:

> I want to create file config.ads similar to config.h but with Ada
> syntax instead of C.
>
> I created config.ads.in, added it to configure.ac and got:
>
> package Boiler.Config is
>Data_Dir: constant String := "${prefix}/share";
> end Boiler.Config;
>
> from
>
> package Boiler.Config is
>Data_Dir: constant String := "@datadir@";
> end Boiler.Config;
>
> It is not acceptable because Ada does not understand ${prefix}.
>
> How to make a value into an Ada string (a string delimited by double
> quotes)?
>
> It could be not ideal but acceptable if the code didn't work with paths
> containing double quotes.

I have no experience with Ada however the general fix is to generate
"config.ads" at "make" time so that $prefix variable will be expanded.
in C you can achieve that with CPPFLAGS:

   AM_CPPFLAGS = -DPACKAGE_LOAD_PATH=\"$(moduledir)\"

With other language this has to be done differently, you can use 'sed'
or 'config.status' in your Makefile.  More details are provided in the
Autoconf manual [1].

[1] 
https://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables

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

Re: Dealing with uninstalled data

[Mathieu Lirzin]

Hello,

Victor Porton  writes:

> What is the best way to debug a program which uses some data files,
> while the program is not yet installed?
>
> For example I have data/classes.ttl to be installed into
> /usr/local/share/boiler/classes.ttl
>
> How can I make my program to use this classes.ttl while it is not yet
> installed?
>
> Maybe, I should lookup in current directory? But that's insecure. Maybe
> I should lookup in current directory only in maintainer mode?

I would recommend using environment variables to override the default
installed directories.  To run you program from build directory can then
use a wrapper script that sets those environment variables appropriately
and call your progam this script can be used for running tests too.  As
an example you can see the 'pre-inst-env' script of Automake [1] which
is generated at configure time.

HTH,

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

[1] https://git.savannah.gnu.org/cgit/automake.git/tree/pre-inst-env.in

Re: automake: tap-driver.sh: cleanup and revival.

[Mathieu Lirzin]

Warren Young  writes:

> On Oct 25, 2017, at 2:51 PM, Mathieu Lirzin  wrote:
>> 
>> Warren Young  writes:
>> 
>>> As for the portability of ANSI terminal escape codes, it’s still best
>>> to delegate such things to curses or libraries like it, despite the
>>> near ubiquity of ANSI-family terminal emulators.
>
> I didn’t quite finish that thought: “…because at the very least, you can then 
> say 'TERM=dumb myprogram’ to strip terminal escape codes on an ad hoc basis.”
>
>> Colors are already automatically used when possible [1] and can be
>> disabled with the AM_COLOR_TESTS environment variable.
>
> Right on.
>
> Any reason it doesn’t back that up with “test -t 1”, though?

I think it does.  :-)

Here is a snippet from lib/check.am which handles the detection:

--8<---cut here---start->8---
am__tty_colors_dummy = \
  mgn= red= grn= lgn= blu= brg= std=; \
  am__color_tests=no

am__tty_colors = { \
  $(am__tty_colors_dummy); \
  if test "X$(AM_COLOR_TESTS)" = Xno; then \
am__color_tests=no; \
  elif test "X$(AM_COLOR_TESTS)" = Xalways; then \
am__color_tests=yes; \
## If stdout is a non-dumb tty, use colors.  If test -t is not supported,
## then this check fails; a conservative approach.  Of course do not
## redirect stdout here, just stderr.
  elif test "X$$TERM" != Xdumb && { test -t 1; } 2>/dev/null; then \
am__color_tests=yes; \
  fi; \
  if test $$am__color_tests = yes; then \
red='[0;31m'; \
grn='[0;32m'; \
lgn='[1;32m'; \
    blu='[1;34m'; \
mgn='[0;35m'; \
brg='[1m'; \
std='[m'; \
  fi; \
}
--8<---cut here---end--->8---

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

Re: automake: tap-driver.sh: cleanup and revival.

[Mathieu Lirzin]

Hello,

Mike Mestnik  writes:

> Somethings I'v spotted that are driving me nuts.
> http://git.savannah.gnu.org/cgit/automake.git/tree/lib/tap-driver.sh#n100
> Clearly indicates that "--color-tests=yes" is the only way to enable
> color, there is no auto-detecting a PTY or any support for the
> documented "--color-tests=always"

The detection is done in the generated Makefile which invokes
tap-driver.sh with the appropriate command line arguments.  Duplicating
detection inside the test driver would make sense only in the context of
invoking it interactively.

Do you have a use case where we would want to invoke tap-driver.sh
outside of the 'make check' context?

Thanks.

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

Re: automake: tap-driver.sh: cleanup and revival.

[Mathieu Lirzin]

Warren Young  writes:

> On Oct 25, 2017, at 8:56 AM, Bob Friesenhahn  
> wrote:
>> 
>>> It's also crazy that "--color-tests=y" or "--color-tests=1" won't work
>> 
>> While I like color in photos and nature, automatic colorization of
>> output often causes problems for me since it often renders the text
>> unreadable.
>
> Why, exactly?
>
> I ask because the default color scheme of some terminal emulators
> makes the dark blue on black text difficult for me to read, but that’s
> easily fixed by switching the color scheme.
>
>> It also introduces terminal escape codes into the text output, which can 
>> cause issues if captured output is later displayed on something other than a 
>> ANSI terminal.
>
> Both problems are caused by programs that hard-code literal ANSI/VT
> codes into text output.  While ANSI-family terminal protocols have
> taken over the world now, that’s still a bad practice which needs to
> be smacked down wherever it reappears.
>
> Well-behaved programs (e.g. GNU ls --color=auto, colordiff…) suppress
> color output when stdout is not a terminal.  They do that by making
> calls like isatty(3) if written in C or test(1) -t if written in
> shell.
>
> As for the portability of ANSI terminal escape codes, it’s still best
> to delegate such things to curses or libraries like it, despite the
> near ubiquity of ANSI-family terminal emulators.

Colors are already automatically used when possible [1] and can be
disabled with the AM_COLOR_TESTS environment variable.

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

[1] 
https://www.gnu.org/software/automake/manual/automake.html#Simple-tests-and-color_002dtests

Re: automake: tap-driver.sh: cleanup and revival.

[Mathieu Lirzin]

Hello,

Bob Friesenhahn  writes:

> On Tue, 24 Oct 2017, Mike Mestnik wrote:
>
>> Is there much interest in keeping this script the way it is or can I
>> lobotomize and release it under a new name?  Suffix of ng is popular
>> these days, tapng-driver.sh. or tap-driverng.sh
>
> It is normal for projects which use this script to copy the script
> into their own source tree.  In this case you are free to name it
> anything you like.
>
> If you have implemented improvements then you should submit a patch to
> the Automake project.

Indeed, contribution for improving tap-driver.sh would be welcome.

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

Re: No rule to make target 'bzr.mk', needed by 'all-am'

[Mathieu Lirzin]

Hello,

Sascha Manns  writes:

> i have a project what provides a file called "bzr.mk". This isnt
> generated and should just installed in $(datadir)/bzrmk.
>
> For doing that i have a src/Makefile.am:
> bzrmkdir = $(datadir)/bzrmk/
> # Not generated
> bzrmk_DATA = bzr.mk
>
> But while building the package i'm getting:
> Making all in src
> make[3]: Entering directory '/build/bzrmk-1.2.1/src'
> make[3]: *** No rule to make target 'bzr.mk', needed by 'all-
> am'.  Stop.
> make[3]: Leaving directory '/build/bzrmk-1.2.1/src'
> Makefile:464: recipe for target 'all-recursive' failed
>
> Full project's url: https://bazaar.launchpad.net/~sascha-manns-h/bzrmk/
> trunk/files

When building from this repository, I have no issue with the
compilation.

> Maybe anyone knows why make searches for a bzr.mk rule?

My guess is that you are trying to build from a tarball generated with
'make dist'.  If my guess is correct, then the issue is that
'src/bzr.mk' is not distributed.  As described in the manual [1], 'DATA'
files are not distributed by default. so you need to prepend 'dist_' to
'bzrmk_DATA'.

HTH,

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

[1] https://www.gnu.org/software/automake/manual/automake.html#Data

Re: bug#13578: Status: A new versioning scheme for automake releases, and a new branching scheme for the Git repository

[Mathieu Lirzin]

Hello,

Mathieu Lirzin  writes:

> Right now we are using this branch naming scheme:
>
>- micro: for next micro version
>- minor: for next minor version
>- master: for next major version
>
> Given the current state of Automake I consider that the main scenario
> for contributing to Automake is either fixing a bug or developping an
> additional feature ontop of the current release version (1.15).  As a
> consequence the current branching scheme requires newcomers to read
> through the HACKING file to understand that they have to base their work
> either on the "micro" or "minor" branch.
>
[...]
> What I am proposing is the following branch name scheme:
>
>- master: for the next version to be released (currently a minor version)
>- maint: for the previous releases (major or minor) merged
> from master and their bug fixing commits leading to a micro
> version release.
>- next: for the "not ready to be release" Automake 2.0 that should
>be merged in master when ready (if ever)
>
> Unless there are better suggestions or valid objections proposed in the
> following week, I will send a request to the Savannah administrators to
> apply the following renaming:
>
>- master -> next
>- minor -> master
>- micro -> maint

After doing that request to the Savannah administrators which has not
been answered after more than 2 months [1]. I have decided to proceed
with the the branch renaming myself by resetting the 'master' branch and
then merging 'minor' into 'master' manually.

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

[1] https://lists.gnu.org/archive/html/savannah-hackers/2017-07/msg2.html

Re: Get the directory of the Makefile

[Mathieu Lirzin]

Hello Victor,

Victor Porton  writes:

> I want to pass absolute (or relative with possible ../../..) path of
> certain file (for example, laying in the same directory as Makefile or
> in its subdirectory or its superdirectory) to my application.
>
> For example, consider that I created application run-tests in a direct
> subdirectory of the Makefile and I want to run
>
> ./run-tests ../data.txt
>
> when I am in a direct subdirectory of the directory with the Makefile,
> because data.txt lies in the same directory as the Makefile.
>
> That is I want Automake to add the correct ../ prefix to data.txt.
>
> How to get the path to my data.txt?

I am not sure to understand what you are trying to do.

A minimal example of a 'configure.ac' and a 'Makefile.am' building
'run-tests' would make easier for us to understand and help you.

Thanks.

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

Re: Automake 1.16

[Mathieu Lirzin]

Hello,

Bob Friesenhahn  writes:

> On Sun, 17 Sep 2017, Thomas Martitz wrote:
>
>> are there any plans to release Automake 1.16?
>>
>> Currently, there is still a nasty bug in 1.15 that is fixed in the
>> development code (I'm talking about the "foo_SOURCES containing
>> variables like $(srcdir)/foo.c" one). Also, I would like to see a
>> release that ships my shorter object file name work. Both issues are
>> raised from time to time, so a release would be welcome.
>>
>> At last, 1.15 is rather old by now. A fresh release would be a good
>> sign of life.

Hopefully 1.15.1 was already a good sign of life.  :)

The commit fixing this bug you are referring to has been made in 2015,
so I agree it should be released soon.  I expect to release 1.16 before
the end of the year.

> I just used ftp to ftp.gnu.org and used 'ls -ltr' of the
> /pub/gnu/automake directory to check upload dates and see that the
> latest Automake is 1.15.1 dated June 19, 2017.  This is not very
> old. Does it still have the bug which is causing a problem for you?

The bugfix was pushed in "minor" branch (for 1.16 release) because it
was considered by previous maintainer as adding an extra feature.  As a
consequence Automake 1.15.1 which was a "micro" release didn't include
it.

Thanks.

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

Re: Portable $addprefix

[Mathieu Lirzin]

Kip Warner  writes:

> On Sun, 2017-08-27 at 19:44 +0200, Mathieu Lirzin wrote:
>> Would something like this work for you?
>> 
>>   files_with_path = `for f in $(files_only); do echo "dir/$$f"; done`
>
> Hey Mathieu,
>
> Thank you for the suggestion. I'm only hesitant to use that because I'm
> not sure if Automake needs to initialize the variable prior to emitting
> Makefile from Makefile.am. Do you know if this is the case?

'files_with_path' will not be interpreted by Automake, it will just copy
the line in the generated Makefile. Since Make variables are macros the
content of the variable will be simply be copied by Make where
$(files_with_path) is used.  As a consequence it should only be used in
the recipe of a rule, not as a target or prerequisite.

> I went to test it, but for some reason I keep getting these errors on
> that line:
>
> Makefile:836: *** missing separator. Stop.

There is a bug in my suggestion.  I guess this error is related to that.

o--8<---cut here---start->8---
files_only = foo.x bar.x baz.x
files_with_path = `for f in $(files_only); do echo "dir/$$f"; done`

all:
@echo "$(files_with_path)"
--8<---cut here---end--->8---

   $ make
   dir/foo.x
   dir/bar.x
   dir/baz.x
   
with that version it seems to work better:

--8<---cut here---start->8---
files_only = foo.x bar.x baz.x
files_with_path = `for f in $(files_only); do printf "dir/%s " $$f; done`

all:
@echo "$(files_with_path)"
--8<---cut here---end--->8---

   $ make
   dir/foo.x dir/bar.x dir/baz.x 

HTH.

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

Re: Portable $addprefix

[Mathieu Lirzin]

Hello,

Kip Warner  writes:

> Hey list,
>
> I'd like to transform the following variable in my Makefile.am from...
>
> files_only = a.foo b.foo c.foo d.foo ...
>
> Into...
>
> files_with_path = dir/a.foo dir/b.foo dir/c.foo dir/d.foo ...
>
> I'm aware of GNU Make's $addprefix magic. I'm also aware it's naughty
> to use where portability is a concern and a different implementation of
> make may be used behind Automake. I was wondering if anyone has come up
> with a recipe for scenarios like this?

Would something like this work for you?

  files_with_path = `for f in $(files_only); do echo "dir/$$f"; done`

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

Re: "Commit Solution Changes" affects unrelated projects and branches

[Mathieu Lirzin]

Hello,

Anton Shepelev  writes:

> Hello, all
>
> When  I  invoke  "Commit  Solution Changes", AnkhSvn
> proposes to commit a lot of projects  that  are  not
> part  of  the  solution,  and  even  some  unrelated
> branches.  Why would it do that?

This question seems unrelated to Automake.  I think this should be
addressed to  mailing-list instead.

Thanks.

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

Re: How to avoid stopping the recursive `check` target?

[Mathieu Lirzin]

Philippe Proulx  writes:

> On Tue, Aug 8, 2017 at 5:06 PM, Mathieu Lirzin  wrote:
>
>>
>> --8<---cut here---start->8---
>> foo_tests = foo/...
>> bar_tests = bar/...
>>
>> TESTS = $(foo_tests) $(bar_tests)
>>
>> check-foo:
>> $(MAKE) $(AM_MAKEFLAGS) TESTS="$(foo_tests)"
>
> I guess you mean:
>
> $(MAKE) $(AM_MAKEFLAGS) TESTS="$(foo_tests)" check
>
>>
>> check-bar:
>> $(MAKE) $(AM_MAKEFLAGS) TESTS="$(bar_tests)"
>
> Same here?

Yes indeed.   :)

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

Re: How to avoid stopping the recursive `check` target?

[Mathieu Lirzin]

Hello,

Philippe Proulx  writes:

> So I put a TESTS variable in a/Makefile.am, b/Makefile.am, and
> c/Makefile.am, and remove the TESTS variable from tests/Makefile.am. Now
> I can go to a/, b/, or c/ and run `make check` to test only specific
> parts of the project. However, since each individual `make check` can
> fail, now the "global" `make check` in tests/ fails as soon as one
> subdirectory fails, which is the expected behaviour of Make.
>
> My current workaround is to use `make --keep-going check` in tests/, so
> that, as per make(1):
>
> Continue as much as possible after an error.  While the target that
> failed, and those that depend on it, can‐ not be remade, the other
> dependencies of these targets can be processed all the same.
>
> This seems to run all the individual `make check` and exit with
> something else than 0 if one of them fails.
>
> I can also wrap this `make --keep-going check` in a new target, for
> example:
>
> test:
> $(MAKE) $(AM_MAKEFLAGS) --keep-going check
>
> Now `make test` does what I want in tests/.
>
> Is there anything more "Automaky" I could do to achieve the same goal?
> Or is using `make --keep-going check` the expected method here if I
> don't want Make to stop as soon as one subdirectory test fails?

I don't know if this is more "Automaky" but for that use case I would
use a non-recursive makefile with custom targets for each subset of
tests.  Here is an untested snippet:

--8<---cut here---start->8---
foo_tests = foo/...
bar_tests = bar/...

TESTS = $(foo_tests) $(bar_tests)

check-foo:
$(MAKE) $(AM_MAKEFLAGS) TESTS="$(foo_tests)"

check-bar:
$(MAKE) $(AM_MAKEFLAGS) TESTS="$(bar_tests)"
--8<---cut here---end--->8---

If you really want the ability to run 'make check' from sub
directories, you can create additional makefiles containing

--8<---cut here---start----->8---
check:
$(MAKE) -C .. check-xxx
--8<---cut here---end--->8---

However I would not recommend it.

HTH,

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

Re: GNU Automake 1.15.1 released

[Mathieu Lirzin]

Werner LEMBERG  writes:

>> We are pleased to announce the GNU Automake 1.15.1 maintenance
>> release.
>
> Thanks a lot for your efforts!
>
> Note that you forgot to tag the new release in the git repository, so
> please do that :-)

I have just added the release tag to the repository.

Thank you for reporting this.  :)

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

GNU Automake 1.15.1 released

[Mathieu Lirzin]

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

This much-needed, bug-fixing release comes after a year and a half of
stalling and inactivity in the Automake development.  The main
motivation for this release is to remove some warnings that were
appearing due to the deprecation of features in Perl and gzip latest
versions.

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

Download here:

  ftp://ftp.gnu.org/gnu/automake/automake-1.15.1.tar.gz
  ftp://ftp.gnu.org/gnu/automake/automake-1.15.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.15.1:

* Bugs fixed:

  - The code has been adapted to remove a warning present since Perl
5.22 stating that "Unescaped left brace in regex is deprecated".
This warning has become an hard error in Perl 5.26 (bug#22372).

  - The generated Makefiles do not rely on the obsolescent GZIP
environment variable which was used for passing arguments to
'gzip'.  Compatibility with old versions has been
preserved. (bug#20132)

* Miscellaneous changes:

  - Support the Windows version of the Intel C Compiler (icl) in the
'compile' script in the same way the (compatible) Microsoft C
Compiler is supported.




signature.asc
Description: PGP signature

Re: ylwrap doesn’t update *.output on failure

[Mathieu Lirzin]

Hello,

Nikolai Weibull  writes:

> It seems that ylwrap doesn’t update *.output on failure.  The *.output file
> is very useful for debugging any failure, so I don’t quite see why this
> isn’t being generated.  Am I thinking about this wrong?

I haven't used Bison much myself so I don't know if you are overlooking
something.

> My AM_YFLAGS are --warnings=all,error --report=all.
>
> A simple fix would be to remove the current if that guards the whole
> file-comparison-and-renaming part of ylwrap and instead add
>
> if $ret -eq 0; then
>   selection=*
> else
>   selection=*.output
> fi
>
> for from in $selection

I would need some advices before fixing this.  I am CCing Tom Tromey (a
previous Automake maintainer) which might have a more enlightened look.

Thanks.

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

Re: AM_CFLAGS and %reldir%

[Mathieu Lirzin]

Hello,

Thomas Martitz  writes:

> when transitioning a project to non-recursive Automake, using
> %reldir%, you lose the ability to define per-directory
> AM_{CPP,C,CXX,LD}FLAGS.
>
> With recursive Automake, you can simply set AM_CFLAGS in each
> Makefile.am. Attempting the same in a non-recursive setup would modify
> the single, global AM_CFLAGS, which may not be desirable.
>
> The only solution seems to be to heavily expand the fragments:
>
> AM_CFLAGS = -g
>
> bin_PROGRAMS = foo bar baz
>
> becomes
>
> bin_PROGRAMS += %D%/foo %D%/bar %D%/baz
>
> %C_foo_CFLAGS = -g
>
> %C_bar_CFLAGS = -g
>
> %C_baz_CFLAGS = -g
>
> (repeat for AM_CPPFLAGS, AM_CXXFLAGS, AM_LDFLAGS).
>
> This gets unwieldy in cases of many programs and libraries. As a side
> effect, Automake will emit explicit rules, making the Makefile even
> larger, though that's not much of a problem I think and is probably
> not avoidable.
>
> Is there any other solution available? I have tried to define
> directory-level AM_CFLAGS, like
>
> AM_%C%_CFLAGS = -g
>
> (applying to all targets that start with %C% after expanding) but they
> are not used.
>
>
> If there are no other solutions, would the above idea considered if
> someone posted a patch?

I think I understand what you mean, however the issue has nothing to do
with %reldir% which is just a convenience for not typing the current
directory of the makefile fragment.

The issue is that you can have only one default AM_*FLAGS per Makefile
and when using a non-recursive Makefile (even with included fragments)
everything is put in a unique Makefile.  When you have a lot of programs
(for example in a test suite), having to define foo_*FLAGS for each
program can indeed be cumbersome.

I like the idea of allowing per directory default flags, I don't see any
issue with such feature.

Regarding the syntax, what about dropping the "AM" in front of
AM_directory_*FLAGS like what is done for per programs _*FLAGS?  IIUC,
it will be impossible to have conflicts between program and directory
flags variables.

Thanks.

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

Re: distcheck does 'chmod a-w' - leads to mkdir "permission denied"

[Mathieu Lirzin]

Paul Jakma  writes:

> On Fri, 3 Mar 2017, Mathieu Lirzin wrote:
>
>> I stopped digging when I saw that I need libcares which is not provided
>> by my distro.
>
> Ah, well, it's only needed for nhrpd, which can be disabled with
> --disable-nhrpd. I'm not sure if the configure script handles it
> correctly though.
>
>> in "doc/Makefile.am" 'quagga_TEXINFOS' contains "defines.texi".  By
>> default files in 'quagga_TEXINFOS' are distributed in the
>> tarball. since "defines.texi" is a generated file you don't want to
>> distribute it.  Putting it in 'nodist_quagga_TEXINFOS' instead
>> should fix your issue.
>
> Even with defines.texi not distributed, or regenerated in the
> distcheck build, it still fails. Cause quagga.info depends on it. :(
>
> I tried nodist_quagga_TEXINFOS and got the same result.
>
> The automake option to build the info in the builddir worked though!

OK.

>> The error message of 'make distcheck' is not really helpful to detect
>> this issue, I am trying to see if something can be done to improve that.
>
> That would be great. :) It's very difficult to figure out the issue
> without help.
>
> Thanks!
>
> Oh, I also had to add:
>
> # do nothing for DVI, so we don't have to generate or distribute EPS
> # figures
> dvi: # nothing

I Will take a look.

> to my doc/Makefile.am, or it would fail checking the 'dvi'
> target. Does anyone use DVI anymore? It's been probably 20 years since
> I did. Does it still need to be a default generated target?

I don't know.  :)

> Now I've got errors from 'distcleancheck', but those are definitely
> ones I wanted to see. ;)

Thanks.

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

Re: distcheck does 'chmod a-w' - leads to mkdir "permission denied"

[Mathieu Lirzin]

Paul Jakma  writes:

> On Fri, 3 Mar 2017, Mathieu Lirzin wrote:
>
>> Can you provide a minimal example that allow others to reproduce the
>> problem?
>
> I have a reproducer, but far from minimal:
>
> (cd /tmp/ && \
>  wget http://download.savannah.gnu.org/releases/quagga/quagga-1.2.0.tar.gz && 
> \
>  cd quagga-1.2.0 && ./update-autotools && \
>  ./configure && make distcheck)

I stopped digging when I saw that I need libcares which is not provided
by my distro.

> It's something in the doc/ build obviously, to make quagga.texinfo,
> but i don't know what...
>
> The other post I found with a similar issue suggested it might be a
> bug in texinfo automake macros?

in "doc/Makefile.am" 'quagga_TEXINFOS' contains "defines.texi".  By
default files in 'quagga_TEXINFOS' are distributed in the tarball.
since "defines.texi" is a generated file you don't want to distribute
it.  Putting it in 'nodist_quagga_TEXINFOS' instead should fix your
issue.

The error message of 'make distcheck' is not really helpful to detect
this issue, I am trying to see if something can be done to improve that.

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

Re: distcheck does 'chmod a-w' - leads to mkdir "permission denied"

[Mathieu Lirzin]

Hi Paul,

Paul Jakma  writes:

> My make distcheck is broken and I can't figure out how to fix it or
> where the problem lies. It seems to be a similar issue to:
>
> http://gnu-automake.7480.n7.nabble.com/cannot-create-directory-am15097-Permission-denied-td209.html
>
> Mine does:
>
> ...
> chmod -R a-w quagga-1.2.0
> chmod u+w quagga-1.2.0
> mkdir quagga-1.2.0/_build quagga-1.2.0/_build/sub quagga-1.2.0/_inst
> chmod a-w quagga-1.2.0
> test -d quagga-1.2.0/_build || exit 0; \
> ...
>
> before going into quagga-1.2.0/_build/sub to do an out of source-tree
> build in _build/sub on the sources in ../.. or quagga-1.2.0. Except
> then at some stage later it fails trying to do a mkdir in
> ../../../doc/ (i.e. quagga-1.2.0/doc):
>
> Making all in doc
> make[3]: Entering directory
> '/home/paul/code/quagga/quagga-1.2.0/_build/sub/doc'
> make  all-am
> make[4]: Entering directory
> '/home/paul/code/quagga/quagga-1.2.0/_build/sub/doc'
>   MAKEINFO ../../../doc/quagga.info
> mkdir: cannot create directory ‘.am18743’: Permission denied
> could not open ../../../doc/quagga.texi: No such file or directory
>
> With V=99:
>
> Making all in doc
> make[3]: Entering directory
> '/home/paul/code/quagga/quagga-1.2.0/_build/sub/doc'
> make  all-am
> make[4]: Entering directory
> '/home/paul/code/quagga/quagga-1.2.0/_build/sub/doc'
> restore=: && backupdir=".am$$" && \
> am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd ../../../doc && \
> rm -rf $backupdir && mkdir $backupdir && \
> if (makeinfo --version) >/dev/null 2>&1; then \
>   for f in ../../../doc/quagga.info ../../../doc/quagga.info-[0-9]
> ../../../doc/quagga.info-[0-9][0-9] ../../../doc/quagga.i[0-9]
> ../../../doc/quagga.i[0-9][0-9]; do \
> if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
>   done; \
> else :; fi && \
> cd "$am__cwd"; \
> if makeinfo   -I ../../../doc \
>  -o ../../../doc/quagga.info ../../../doc/quagga.texi; \
> then \
>   rc=0; \
>   CDPATH="${ZSH_VERSION+.}:" && cd ../../../doc; \
> else \
>   rc=$?; \
>   CDPATH="${ZSH_VERSION+.}:" && cd ../../../doc && \
>   $restore $backupdir/* `echo "./../../../doc/quagga.info" | sed
> 's|[^/]*$||'`; \
> fi; \
> rm -rf $backupdir; exit $rc
> mkdir: cannot create directory ‘.am1976’: Permission denied
> could not open ../../../doc/quagga.texi: No such file or directory
> /bin/sh: line 16: cd: ../../../doc: No such file or directory
> Makefile:493: recipe for target '../../../doc/quagga.info' failed
>
> I'm a bit mystified as to where to start looking. It don't see
> anything obvious in the doc/Makefile.am. The only thing is we have a
> 'defines.texi' that is built by automake from defines.texi.in and
> declared as:
>
>  BUILT_SOURCES = defines.texi
>

Can you provide a minimal example that allow others to reproduce the
problem?

Thanks.

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

Re: variables in _SOURCES

[Mathieu Lirzin]

Hello,

Daniel Pocock  writes:

> According to the "Warning" in this page[1], it is not permitted to use
> variables in _SOURCES.  Is this deliberate or is it a bug?
>
> In our project, we started getting the warnings about subdir-objects and
> so we added[2]
>
>   AM_INIT_AUTOMAKE([foreign subdir-objects])
>
> However, since that time the build has been failing[3] and it appears to
> be because one module[4] is using a variable in _SOURCES
>
> The $PYCXX_SRCDIR variable is used to refer to the sources provided by
> the PyCXX[5] library.  PyCXX is not distributed as a compiled library
> that can be linked against, the sources are simply placed under
> /usr/share by the packages (e.g. on Debian[6]) and users have to compile
> them into their projects by referring to them from their Makefile.
>
> What is the recommended way of using such sources in a build?  I could
> write some Makefile rule to copy or symlink the sources in to the tree,
> but is there an official way to solve this with autotools?

The idiomatic way is to distribute every source files that could be
built.  One way to achieve that would be to make a 'bootstrap' script
that fetches PyCXX sources before doing ‘autoreconf -vfi’.

-- 
Mathieu Lirzin

Re: AC_SUBST'ing foodir correctly?

[Mathieu Lirzin]

Wouter Verhelst  writes:

> On Tue, May 24, 2016 at 06:11:47PM +0200, Mathieu Lirzin wrote:
>> 
>> ‘systemdsystemunitdir’ seems not affected by DESTDIR because IIUC
>> PKG_CHECK_VAR set it to something like "/lib/systemd/system" instead of
>> "${libdir}/systemd/system".
>> 
>> I suppose it would work better to define it manually like
>> this:
>> 
>>   if SYSTEMD
>> systemdunitdir = $(libdir)/systemd/system
>> systemdunit_DATA = nbd@.service
>>   endif
>
> Well. That would work, yes, but it wouldn't work *better*. The whole
> point is that I do not want to hardcode such things, so that if a user
> installs systemd units in  and the
> pkg-config files are where they need to be, everything works as expected.

You are right, that would be better.  My understanding is that
pkg-config files are supposed to define variables in terms of 'prefix'
as described in pkg-config(1)

--8<---cut here---start->8---
  prefix=/home/hp/unst   # this defines a variable
  exec_prefix=${prefix}  # defining another variable in terms of the first
  libdir=${exec_prefix}/lib
  includedir=${prefix}/include
--8<---cut here---end--->8---

but “systemd.pc” isn't doing that.

> I was under the impression that automake looks at DESTDIR for every
> foodir it looks at, but apparently that's not the case then? That seems
> broken; after all, I don't think a staging directory should depend on
> whether or not something was part of a given prefix. Is there any
> explanation available somewhere on why this behaviour occurs? Would a
> patch that changes this behaviour be acceptable?

Every default installation directories are expected to be subdirectories
of the 'prefix' variable.  This is verified by ‘make distcheck’ and
specified in GNU coding standards:

  
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

So it is unlikely that a patch is going to be accepted in Automake.
However I guess the default pkg-config file could be fixed in Systemd.

Thanks,

-- 
Mathieu Lirzin

Re: AC_SUBST'ing foodir correctly?

[Mathieu Lirzin]

Hi,

Wouter Verhelst  writes:

> I'm adding a systemd unit to my package. To that end, I'm checking if
> there is a pkg-config .pc file for systemd which sets a variable
> "systemdsystemunitdir", and am trying to install the systemd unit in
> that location.
>
> I'm currently doing this:
>
> AC_MSG_CHECKING([for systemd unit file locations])
> AC_ARG_ENABLE(
>   systemd,
>   AS_HELP_STRING([--disable-systemd],[Do not install systemd support files 
> (or use --enable-systemd to fail build when not available)]),
>   [
> if test "x$enableval" = "xyes"; then
>   ENABLE_SYSTEMD=yes
> else
>   ENABLE_SYSTEMD=no
> fi
>   ],[]
> )
>
> if test "x$ENABLE_SYSTEMD" != "xno"; then
> 
> PKG_CHECK_VAR([SYSTEMDUNIT],[systemd],systemdsystemunitdir],[AC_SUBST([systemdunitdir],
>  [$SYSTEMDUNIT])])
> fi
>
> and then in my Makefile.am:
>
> if SYSTEMD
> systemdunit_DATA = nbd@.service
> endif
>
> (if you need the full files, they're in the git repository at
> git.debian.org/users/wouter/nbd.git)

This URL doesn't work for me.

> However, now my "make distcheck" fails, because the "make install"
> target disregards DESTDIR and tries to install files in the actual
> systemd unit directory, rather than the staging one. Clearly this means
> I'm doing something wrong, but I'm not sure what the proper way for
> doing this would be.

‘systemdsystemunitdir’ seems not affected by DESTDIR because IIUC
PKG_CHECK_VAR set it to something like "/lib/systemd/system" instead of
"${libdir}/systemd/system".

I suppose it would work better to define it manually like
this:

  if SYSTEMD
systemdunitdir = $(libdir)/systemd/system
systemdunit_DATA = nbd@.service
  endif

and keep only the feature test in configure.ac followed with the
Automake conditional.

-- 
Mathieu Lirzin