Re: Add support for generating HTML docs a` la PDF, etc.
Hi Alexandre, I'm cc:ing you often these days. It's nice to be included :). The discussion is about introducing a `make html' target to Automake. Good. AFAICT `makeinfo --html --no-split' creates file named `mumble.html', while `makeinfo --html' creates a directory named `mumble.html/'. Correct (well, it depends on the @setfilename too, but you know that). So it seems we could handle both cases with `rm -rf mumble.html'. I concur. For instance using a $(MAKEINFO_html) variable as the command, something similar for the options. I agree again, that variable overriding is better than an automake option for this need. Guess you didn't need me after all :). Thanks, karl
Re: readme-alpha option and .90 pretests
comes from the Gnits standards. There is no such thing as Gnits standards. I was/am a founding member of gnits (which was just a few friends talking informally), and I can state this authoritatively :). Before automake existed, there were various autoconf/installation/etc. conventions that a few of us developed and followed, for personal amusement as much as anything. They were never written down or made official in any way, partly because Tom implemented them in the early days of automake, so they didn't need a separate existence :). In fact, the whole gnits thing should probably be eradicated from automake, except for historical purposes. Maybe we should have a way to tell Automake about the version numbering scheme used by a package? Well, if you want to make work for yourself :). What seems most logical to me is for automake to implement the GNU standard in these matters, at least as the default. Which is actually written down. Karl Did anyone ever make a test release with a version number like 4.5.1? Coreutils. Jim will never do it again :).
Re: readme-alpha option and .90 pretests
Perhaps you should tell the people behind: The gnit-picker gang, like I said, was a few friends, not an official group of any kind. I was one of them. http://www.amath.washington.edu/~lf/tutorials/autoconf/gnits/gnits.html Ah. It's been enough years that I'd forgotten that François (Pinard) had made up a skeleton gnits document, augmenting and with the same layout as the GNU coding standards. It was never supposed to be published. I don't see any email addresses at http://www.amath.washington.edu/~lf, so I can't write to him/her asking to remove it. I don't know who lf is, none of the gnits'ers have those initials. In any case, I'd guess it's been copied to a zillion places by now. All I can say is, again, the Gnits standards aren't real. Automake should just follow the GNU coding standards. If you don't believe me, you can write to [EMAIL PROTECTED] (a mailing list and domain that I maintain/own, by the way :). Note that even if you accept that document (which is fine, for what it is), it says GNU standards take precedence by a mile. Thanks, k
Re: txinfo trivial failures
| This is TeX, Version 3.14159 (C version 6.1) (format=tex 98.7.5) 21 AUG 2003 20:18 Yes, this version of TeX predates --help and the like, so TeX just takes the string as input. If you feel like updating your TeX installation, check http://tug.org/tetex or http://tug.org/texlive. So I think texi2dvi should be changed to clean texput.log afterwards (or run tex --help in a temporary directory). I agree, I will work on that for the next release. Thanks.
Re: html texinfo install?
Doesn't pretty much every distribution use /usr/share/doc for this and other package documentation at this point? Sure, many distributions do this, on a per-package per-version basis as far as I know. /usr/share/doc/emacs-21.2, etc. The distribution makers do it all themselves, it's nothing specified in the GNU standards. This would be a pretty huge change for distributions, particularly since many of them have tools to index /usr/share/doc, web servers that serve it out to localhost, etc. They don't have to change anything. All that will happen is, if HTML installation is enabled at installation, it'll also be available under (say) /usr/share/texinfo/html/emacs/ -- just like /usr/share/info. Anyway, on my redhat 9 system, ditto Debian (the two I can easily check), HTML files are not installed for GNU packages -- precisely because, I imagine, there is no standard target to do so, exactly what we're trying to remedy. It's just the ChangeLog, NEWS, README, and other random files from the distribution. Anyway, /usr/share/doc/package-version doesn't solve the cross-manual xref problem, because of the -version and random subdirectory structure.
Re: [help-texinfo] Re: translating automake infopage
I wonder if tools similar to gettext exist for manuals? FWIW, I have never seen any. Something based on wdiff might be better than straight diff. E.g., does `info' supports several translated versions of a manual? There is no special support for translations in the Texinfo system. In fact, there is little support for languages other than English (although some non-English manuals have been written). This is of course a very serious deficiency, but it's not easy to remedy, and I regretfully have not had time to do much about it. If yes, where should they be installed and how should they be named? There is a French translation of the Info manual. It's named info-fr.texi and info can access it just like any other manual. FWIW. A better approach would probably be $(infodir)/fr/info.texi. But this actually requires changing the code to figure out where to look under what circumstances, and thus hasn't been done. (I see nothing about this in the Texinfo manual, but maybe there are plans for this.) It's come up many times. Wish I had better news to report.
targets to handle gnu dist procedures?
John Darrington (cc'd here), who maintains the GNUbik package, made this suggestion: With the new ftp upload procedures, shouldn't the automake targets be changed appropriately? In particular: The dist target should generate the package.tar.gz.asc file and the dist-check target should verify that this signature is indeed valid. I myself don't think it should be part of dist and distcheck. Doing the signature requires typing the pass phrase. It often takes a dozen runs of dist[check] before the release is actually ready (at least for me). I would be quite annoyed at having to do the signature stuff on every test run. Having a separate target to do it, however, could be useful. Maybe even make the directive file and sign it, too, with a variable that defaults to $PACKAGE for the directory name. (Some variables would also be necessary for the gpg invocations, of course.) What do you think? Best, karl
gnupload example
gnupload --help has this example: gnupload ... --to alpha.gnu.org:automake \\ ... I suggest changing it to: --to alpha.gnu.org:gnu/automake \\ Otherwise, there is a possible confusion that gnupload puts in the gnu/ for you. (This confused me for a while, silly me.) Thanks, Karl
Re: GNITS being referenced, with no link...
Personally, I'd be happy if gnits disappeared from automake completely, except for being invisibly implemented as a synonym for `gnu'. Does it really serve a purpose any more? Even those of us who were/are part of the actual gnits group no longer use that option. Thanks, Karl
proper autotools ordering?
I've been looking through the manuals and code, but not finding a definitive answer: is there a canonical/recommended ordering of running the autotools, including automake? I've been using aclocal - autoheader - automake - autoconf for years, but have no idea any more where I got that ordering. I see that autoreconf runs autoconf before autoheader, and ah before am, so I suppose this is it: aclocal - autoconf - autoheader - automake. Whatever the answer is, I suggest adding it to the manual(s). Thanks, karl
Re: -local vs. -hook?
+You may be tempted to use @code{install-data-local} to install a file
+to some hard-coded location, but you should avoid this.
+(@pxref{Hard-Coded Install Paths})
Shouldn't the period be moved from after this to after the closing
parenthesis?
Yes.
+With the @code{-local} targets, there is no particular guarantee of
+execution order; typically, they are run early, but with parallel
+make, there is no way to be sure of that.
There isn't even consistency among the various -local targets in their
ordering wrt. other targets. In fact, I wouldn't even know how many of
them are run at what time, so I'm a bit wary of the typically
statement.
By all means, delete typically if you prefer. I was just copying
(with rewording) from your mail :).
Thanks,
k
gnupload and ncftpput
Hi Ralf and everyone, I received a suggestion to mention gnupload in the GNU maintainers manual, since it's the easiest way (that I know of, anyway) to upload files to ftp.gnu.org and alpha.gnu.org. However, there is one issue I felt should be mentioned to do so: the dependency on ncftpput. Personally, I don't have ncftp installed on all the myriad machines I upload from, and I don't really want to depend on it, either. So (a long time) I wrote a shell script that uses plain-old-ftp (BSD-based, like the one in GNU inetutils) to do the same job with the same interface, which I simply name ncftpput in my PATH. It's attached. So, I guess my questions are: 1) do you have any interest in eliminating the dependency on ncftpput? 2) do you have any interest in including this ncftpput-replacement somewhere, somehow? Probably most maintainers do have ncftpput; in any case, it's hardly critical. I suppose I could put the script in, say, the gnustandards repository, or maybe gnulib, and people who want it could get it. I am not exactly sure of the best way to proceed. (I see I used a bash-ism in my script, and I did not attempt to make perfectly robust, etc., but that could all be solved if there is a need.) Thoughts, reactions? Thanks, k ncftpput-ftp.sh Description: Binary data
Re: gnupload and ncftpput
1) do you have any interest in eliminating the dependency on ncftpput?
Sure.
So perhaps the best outcome would be for gnupload to use ftp itself,
instead of ncftpput? Ie, this stuff could become a function in
gnupload?
Failing that, perhaps gnupload could use a variable, e.g.,
: ${FTPPUT=ncftpput}
to make it easier to use something else.
- missing basename could be taken care of.
What do you mean? If the result of calling basename is the empty string?
Re: gnupload and ncftpput
Not sure whether ftp is universally available, though. A lot more universally than ncftpput, I expect. If you want me to prepare a patch, I'll try. If you'd rather not bother with it, I'll just write about putting the replacement script into gnulib. I don't have strong feelings about it either way. According to the Autoconf manual, some systems don't have a working basename. Wow. That was one original Unix utility which I thought could be relied on. I guess we don't need to cater for those here, presumably very old systems. I guess so too. Thanks, k
Re: gnupload and ncftpput
Just to resolve this ... I guess I'll just upload my ncftpput replacement script elsewhere. It's not worth any of our time to prolong the discussion. Thanks, k
Re: reword documentation about symbol stripping (was: default -g ??!?)
Karl, what do you think about this rewording The second hunk adds real information, so I'll go ahead and install that. The first hunk, though, I just can't agree with, and I feel pretty sure that rms would not approve of such a change either. Helpless is a good description of people faced with crashing executables without debugging symbols. Empowering everyone on equal terms is part of the overall GNU philosophy, after all. I personally would not have written it that way in the first place, but given that it is there now, I don't want to simply replace it with bland text, or occupy rms's time with it, either. Best, karl
Re: reword documentation about symbol stripping
it addresses an issue that
some people may not know about, so maybe it would be good to briefly
explain further?
I agree, thanks. I changed the text to look like this:
By default, the Make rules should compile and link with @samp{-g}, so
that executable programs have debugging symbols. Otherwise, you are
essentially helpless in the face of a crash, and it is often far from
easy to reproduce with a fresh build.
Best,
karl
AM_PROG_MKDIR, gettext, and automake
- The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will next major Automake version (1.13): Yes, well, speaking of AM_PROG_MKDIR. We don't use it explicitly in Texinfo. But I get the warning about it every time I rerun automake, because our configure.ac includes the usual line: AM_GNU_GETTEXT([external]) The result of that line is: configure.ac:260: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and will soon be removed. configure.ac:260: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead, configure.ac:260: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files. (which is quite annoying, since it's not under my control, but anyway.) I have the latest official release of gettext, 0.18.1.1 (although unfortunately gettext --version evidently drops the final .1). Also of automake, 1.12.5. I see that Jim discovered this back in July: http://lists.gnu.org/archive/html/automake/2012-07/msg00014.html but I'm afraid I cannot discern what the resolution was. For that matter, I can't see how there can be any good resolution until there is a new gettext release. Was the problem reported there? I didn't see it in the various archives. At any rate, also unfortunately, as gettext is now looking for a maintainer (as I just posted, http://lists.gnu.org/archive/html/bug-gettext/2012-11/msg2.html), a new release might be quite some time coming in any case. Meanwhile, it seems like it would be a tremendous, and unnecessary, headache if there was an Automake release that removed a macro that the current release of gettext requires. But I guess we can wait and see whether the next gettext or automake 1.13 is ready first ... karl
EXTRA_DIST, directories, tar --exclude-vcs
Stefano and all, It would be nice to able to list directories in EXTRA_DIST. It is painful and unnecessary overhead to list every file in a contrib directory individually just to avoid including VC files. (As explained at http://www.gnu.org/software/automake/manual/automake.html#Basics-of-Distribution.) I don't propose any major surgery to make it work in every conceivable circumstance. All that is really necessary is to provide a way to pass --exclude-vcs to tar. It would only work with GNU tar, but that is ok. What worked for me is to override the definition of am__tar, like this in Makefile.am: am__tar = tar --exclude-vcs --format=ustar -chf - $$tardir Except I don't really want to put this into Makefile.am. Happily, this also worked from the command line: $ env am__tar='tar --exclude-vcs --format=ustar -chf - $tardir' make dist For that matter, it would be nice if am__tar provided a way to pass arbitrary extra options. Perhaps include something like $(AM_TAR_USER_OPTIONS) in the definition? Equivalently, provide a way to override the name tar, as in $(AM_TAR_PROGRAM)? That might be simplest of all. Along those lines, it would be nice if Automake always used the -chf style above. In some distributions' Makefiles I've seen chf (didn't look into why); that prevents adding options though, due to the vagaries of tar command line parsing which we all know. I have the impression that every tar (except maybe really ancient ones, can't remember, but we don't care) supports the -style. Sorry for the brain dump of all these possibilities, but wdyt? k
Re: Improvements to dist targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)
that every tar (except maybe really ancient ones, can't remember, but we don't care) supports the -style. It would be nice to verify this claim on as much systems as possible Certainly POSIX has always required supporting -options, which is some 15 years old at least. Or do I mean 25? Either way ... And in practice, every system I've ever used has a system tar supporting -options, not just old-style options without the -. Thus I would still propose that Automake always use -options to tar in its output, never old-style options. As for tar-v7, tar-ustar, tar-pax ... I don't know. k
Re: Improvements to dist targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)
That is already possible: http://www.gnu.org/software/automake/manual/automake.html#The-dist-Hook I see. Given this, I propose merely changing the definition of am__tar to use variables. Something like: am__tar = $(TAR) $(TAR_OPTIONS) - $$tardir where the actual definitions of TAR and TAR_OPTIONS remain as they are now (except possibly always using -options, as I'm replying to separately). That would make it easy for people to change or add anything they want to change, in various ways. I'm not sure if TAR and TAR_OPTIONS would be the conventional names; any names would do, as far as I'm concerned. k
Re: Improvements to dist targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)
OTOH, what about distribution tarballs in '.zip' format? They don't use tar at all ... Time to deprecate them maybe? Is anybody actually using them? And while at it, what about the even more obscure 'shar' format? FWIW, I think they should still be supported. I see recent distributions on ftp.gnu.org using both -- gzip and tar make shar archives for the sake of bootstrapping, and some packages use zip to make things easier for Windows users. One could certainly make arguments about getting rid of them (especially shar), nevertheless. I personally wouldn't want to spend time engaging in that debate :). k
combined report for make check?
Especially for packages which run make check in several subdirectories (e.g., texinfo), Nelson Beebe made the suggestion that it would be helpful if there was an overall textual report of success or failure, and not just the exit status. Something like ALL TESTS PASSED vs. FAILED TESTS. Leaving it to the user to go back and examine the full log to see which ones in which directories. The idea being that people (like Nelson) building on many systems could just grep for that string in the build logs and determine which ones need further inspection. I'm not sure how feasible this is, but I thought I'd at least bring it up. Thanks, k
Re: combined report for make check?
This would require to change the 'check-recursive' targets not to share the same code with the other '*-recursive' targets. I really don't want to go there. Totally reasonable :). The best solution is on the user-side IMHO: fix the build system to use less (ideally none) make recursion. I don't know what you mean. Texinfo has several separate programs, each with their own tests. Isn't subdirectory recursion the natural way to do it? How else? For that, a screen scraping script wrapping the 'make check' invocation Yeah. My related idea was that his build script could run something like make check || echo *** tests failed or whatever ... Thanks, Karl
Re: combined report for make check?
With a non-recursive, top level Makefile. Quick example: So, replace a nicely separated source setup with munging together the information about everything in one place? Thanks for the suggestion, but that seems like a major step backwards in maintainability to me, so I'll decline. Life goes on. k
Re: Problems with gnits standard and git-version-gen
1.00rc0 Personally, when I see a version number like that, I'm never sure what it means. Probably the first rc leading up to 1.00, but maybe it is an rc for 1.01 after 1.00. And suffixes sort badly in long lists (see, e.g., http://ftp.isc.org/isc/bind9/). Anyway. Not trying to change your ways, but since you raised the subject, tossing in my gratuitious opinion, sorry. gnits standard gnits is not a standard of any kind. It was a small group of GNU friends who, some 20+ years ago, wanted to expand on the GNU coding standards (which were not being actively maintained at the time, among other reasons). One of us was Tom Tromey, writing automake at the time. So he included support in automake for the extra gnits checks we were thinking about. That is all. If you don't like it, don't use it. No harm will befall you. doesn't allow non-numeric suffixes... Because it's not what rms recommended. That simple. As you may remember, we used to use 1.7a, 1.7b, ..., leading to up a 1.8 release. Someone complained about it, can't remember who, maybe Debian, but anyway, rms devised the .90, .91, ... method to accommodate. And since it's just a version number, many maintainers were happy to just go along with the new program. k
handling --program-transform(s) in hooks
Question: how best to respect --program-suffix, --program-prefix, --program-transform-name in user-defined rules for installing? Details: For Texinfo, I install makeinfo as a symlink to texi2any in the install-exec-hook (like the example in the Extending node of the automake manual): install-exec-hook: rm -f $(DESTDIR)$(bindir)/makeinfo -$(LN_S) texi2any $(DESTDIR)$(bindir)/makeinfo However, clearly this ignores any specified program transformations. Glenn (Morris, cc'd) reported as follows: I configured texinfo-5.2 like this: ./configure --program-suffix-5 make install created a broken link in bin/: makeinfo - texi2any This should be: makeinfo-5 texi2any-5 True enough. So my question is, how best to deal with it? I mean, I can look at the output and hack the same sed invocations that automake inserts into Makefile.in into my install rule. But I wonder if there is a better way, perhaps using something other than install-exec-hook. Any advice? Other Automake-using programs to look at for emulation purposes? (I looked at a few without much luck.) I see that Emacs does stuff like this: # Program name transformation. TRANSFORM = @program_transform_name@ # What emacs should be called when installed. EMACS_NAME = `echo emacs | sed '$(TRANSFORM)'` which seems sensible enough, but Emacs only uses autoconf, not automake. Not sure that using @program_transform_name@ is the best way to go. In any case, I suggest this issue be addressed in either the Renaming or Extending node of the manual (with a pointer from the other one). At least, those are the places I found that seemed likely to be relevant. If it's in the manual somewhere else, please let me know. I couldn't find anything specific about this in general web searches, stackexchange, etc., either, which surprised me, since surely this come up before in all these many years. Perhaps I couldn't figure out the right thing to search for. Thanks, Karl
automake needs a new maintainer
Hello Automake folks, The last Automake release was not that long ago (December 2013), but Stefano (Lattarini) has mentioned that his time for Automake has become extremely limited; likewise with the other two current maintainers, Ralf Wildenhues and Jim Meyering. So we're hoping that some experienced Automake person would like to come forward and become the new active maintainer -- dealing with bug reports, pushing new releases, and so on. (I say experienced because Automake is not the place for a new developer to start learning.) The present need is not to rewrite Automake into some new-generation thing, or otherwise undertake intensive new development. Rather, just continue to keep the existing package in a good shape. Of course, new work is welcome, but as everyone here surely now, compatibility must be an overriding concern when it comes to Automake. There is some general information about maintaining GNU packages at http://www.gnu.org/help/evaluation.html#whatmeans -- written in the context of a new package being offered to GNU, but most of it is relevant to anyone interested in maintaining a package. If you're interested, please write maintain...@gnu.org, and thanks. Karl
Re: automatically showing test-suite.log on failure?
>I might be missing something, but I get that behavior in my automatic >builds by calling 'make check VERBOSE=1'. This does not appear to have any effect when using the TAP framework. So it seems. From grepping the installed automake, I see VERBOSE used in exactly one line of code: am/check.am:373:test x"$$VERBOSE" = x || cat $(TEST_SUITE_LOG); (All the other occurrences are about Automake's V= verbosity feature, I believe.) But since in my project (TeX Live) we have always used the regular driver, I am happy :). --best, karl.
Re: automatically showing test-suite.log on failure?
I might be missing something, but I get that behavior in my automatic builds by calling 'make check VERBOSE=1'. Yes! Thank you!!
automatically showing test-suite.log on failure?
After make check runs, if there were any failures, I'm wishing for a way to have automake to automatically show the relevant test-suite.log. The post at https://stackoverflow.com/questions/20961959 suggests that the only way to do this is to modify the test-driver script. Is that correct? There isn't a target or variable that can be set to achive this, like a "cat test-suite.log" command somewhere/somehow? I didn't see anywhere to hook in in the generated Makefile[.in]s, but I certainly could have missed it. (That post says the clean-local target never gets run in the case of failure; I didn't confirm it ...) If nothing else, I guess it could be done by writing my own little LOG_DRIVER script that invokes the real test_driver and then looks at the result. (I haven't tried it.) I certainly don't want to modify the distributed test-driver, as that would not be future-proof ... However, this seems like it would be fairly commonly useful and easy enough to do in the canonical test-driver script. So, any chance of adding it as a standard feature? Any reasonable way of enabling it would be fine, e.g., a flag that can be added to [AM_]LOG_DRIVER_FLAGS. BTW, as with that post, I'm primarily interested in this because of automated build environments where all that is (easily) seen is the log. Secondarily, in a big build tree, and with srcdir!=builddir, it can be annoying just to navigate to the correct test-suite.log file. Thus it would be nice to just have it up front. Thanks, Karl
VERBOSE=1 in [AM_]TESTS_ENVIRONMENT doc/feature
It seems the VERBOSE variable is documented in only two places in
automake.texi, and neither place gives examples:
In Parallel Test Harness
If the variable @samp{VERBOSE} is set, this
file is output after the summary.
In Overview of Custom Test Drivers Support:
use of @code{VERBOSE} environment variable to get verbose output on
testsuite failures;
(Incidentally, it seems that both uses should either be @samp or @code,
not one of each. :)
As the long thread starting at
http://lists.gnu.org/archive/html/automake/2015-05/msg8.html
shows, this has occasionally lead to confusion. It feels natural to set
VERBOSE = 1
in a Makefile.am, either on its own or as part of [AM_]TESTS_ENVIRONMENT,
but this does not work.
Thus I suggest
(1) adding "environment" before "variable" in Parallel Test Harness, and
(2) adding a few more words:
This is typically set on the command line, as in
@samp{make VERBOSE=1 check}. It does not work to set @code{VERBOSE} in
@code{Makefile.am} or as part of @code{AM_TESTS_ENVIRONMENT} or
@code{TESTS_ENVIRONMENT}.
At least that would give more of a clue as to usage. I don't see a need
to get into GNU make "export VERBOSE=1" features, etc.; "environment" is
the key fact.
Alternatively, allowing VERBOSE=1 to be set as part of
[AM_]TESTS_ENVIRONMENT seems feasible. Those envvars are in
am__check_pre, which is expanded before any $(LOG_DRIVER) call. So
expanding it before the of test of $$VERBOSE seems like it should
suffice. That is, deep in the $(TEST_SUITE_LOG) target, the line
test x"$$VERBOSE" = x || cat $(TEST_SUITE_LOG); \
could become
$(am__check_pre) test x"$$VERBOSE" = x || cat $(TEST_SUITE_LOG);
\
When I tried it (by editing the generated Makefile), it seemed to work ok.
(Perhaps it would be better to do it at the beginning of
$(TEST_SUITE_LOG), but that's a judgement call I can't make.)
Happy hacking,
Karl
t/txinfo-vtexi4.sh and timezone failure
The automake test t/txinfo-vtexi4.sh failed when localtime and UTC were on different days, resulting in the GREPDATE for the @UPDATED@ string not matching (among possible others). mdate-sh always uses TZ=UTC0. This tiny change makes the test do the same thing. I wondered if there were other tests that might have the same problem, e.g., if TZ would be better set in test-init.sh (although granted this was the only one failing). However, install-sh-option-C.sh is the only other test that was setting TZ, and I didn't see others invoking date, either. So Jim and I figured just patching vtexi4 is reasonable. Unrelated but so trivial did not at all seem worth separating: the doc in vtexi4.sh referred to itself when it didn't mean to. Any comments or suggestions before I attempt to push this? --thanks, karl. txi-test-tz.diff Description: Binary data
Re: minor docs alteration
Hi Jefferson,
Thanks for this suggestion from May 2018 (oops).
Date: Thu, 31 May 2018 22:44:45 +
From: Jefferson Carpenter
To: automake-patc...@gnu.org
Subject: minor docs alteration
-The build tree is rooted in the directory in which @file{configure}
+The build tree is rooted in the directory from which @file{configure}
I just pushed several wording changes along these lines, hoping to
clarify the build tree location even more ... --best, karl.
index 4b26677..9f4acf6 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -860,13 +860,14 @@ Manual}, for more information about this feature.
@cindex trees, source vs.@: build
The GNU Build System distinguishes two trees: the source tree, and
-the build tree.
+the build tree. These are two directories that may be the same, or
+different.
-The source tree is rooted in the directory containing
-@file{configure}. It contains all the sources files (those that are
+The source tree is rooted in the directory containing the
+@file{configure} script. It contains all the source files (those that are
distributed), and may be arranged using several subdirectories.
-The build tree is rooted in the directory in which @file{configure}
+The build tree is rooted in the current directory at the time @file{configure}
was run, and is populated with all object files, programs, libraries,
and other derived files built from the sources (and hence not
distributed). The build tree usually has the same subdirectory layout
@@ -880,8 +881,8 @@ installation example (@pxref{Basic Installation}).
A common request from users is that they want to confine all derived
files to a single directory, to keep their source directories
-uncluttered. Here is how we could run @file{configure} to build
-everything in a subdirectory called @file{build/}.
+uncluttered. Here is how we could run @file{configure} to create
+everything in a build tree (that is, subdirectory) called @file{build/}.
@example
~ % @kbd{tar zxf ~/amhello-1.0.tar.gz}
Re: t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED
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. Other than that, please push asap! --thanks again, karl.
t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED
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?
Thanks,
Karl
P.S. This also fails for me if I run make installcheck after
building the released automake-1.16.
P.P.S. There are two other tests, print-libdir and aclocal-print-acdir,
which also fail at the make installcheck step of make distcheck, and not
sooner. Unfortunately they are not solved by unsetting
AUTOMAKE_UNINSTALLED, though I think the problem is generally similar.
dependency tracking error message
Looking at the automake-patches that have accumulated, I saw one to improve the error message if dependency tracking fails. Copied below. It seems generally sensible to me, though I would change the wording a little, and there is a spurious "the", so, revising the proposed text: AC_MSG_FAILURE([Something went wrong bootstrapping makefile fragments for automatic dependency tracking. If GNU make was not used, consider re-running the configure script with MAKE="gmake" (or whatever is necessary). You can also try re-running configure with the '--disable-dependency-tracking' option to at least be able to build the package (albeit without support for automatic dependency tracking).]) Confirm/deny? Further suggestions? --thanks, karl. >From 040f4cc6b8300af4812549d69b07926e5423988a Mon Sep 17 00:00:00 2001 From: Libor Bukata Date: Thu, 23 May 2019 12:31:31 +0200 Subject: [PATCH] Improve the error message when the dependency tracking fails The dependency tracking may fail with a non-intuitive error that "Something went wrong ..." if the package expects GNU make to process its Makefile.am files and other make implementation is used by default (e.g., Solaris make). This patch adds a hint to the error message that the user may try to specify GNU make command as a configure argument. Related bug with discussion: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35848 * m4/depout.m4: Added a hint to the error message. --- m4/depout.m4 | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/m4/depout.m4 b/m4/depout.m4 index 431c07d..b8cec38 100644 --- a/m4/depout.m4 +++ b/m4/depout.m4 @@ -38,10 +38,12 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS], | $MAKE -f - am--depfiles]) || am_rc=$? done if test $am_rc -ne 0; then -AC_MSG_FAILURE([Something went wrong bootstrapping makefile fragments -for automatic dependency tracking. Try re-running configure with the -'--disable-dependency-tracking' option to at least be able to build -the package (albeit without support for automatic dependency tracking).]) +AC_MSG_FAILURE([Something went wrong during bootstrapping of makefile +fragments for automatic dependency tracking. If the GNU make is not +used by default, consider to rerun the configure script with MAKE="gmake". +You can also try to rerun configure with the '--disable-dependency-tracking' +option to at least be able to build the package (albeit without support +for automatic dependency tracking).]) fi AS_UNSET([am_dirpart]) AS_UNSET([am_filepart]) -- 1.8.3.1
Re: Warning category skew between Autoconf and Automake - workaround in autoreconf?
Hi Zack - in addition to the other replies, how do you prefer to do the sync? (which it seems like we might as well do asap.) From am to ac, or from ac to am? I don't think it makes much difference, and am happy with either direction. I admit I'm also not sure offhand how to integrate it with "make fetch", whichever direction it goes. Patch would be welcome :). --thanks, karl.
Re: AC_DIAGNOSE not obsolete, please
The second set, applicable to automake, is additional tweaks I needed to make to the automake testsuite to get it to pass 100%. Thanks much (again and again), Zack. Certainly looks fine to me. Please go ahead and commit to automake at your convenience. --happy hacking, karl.
Re: Relative path without realpath
The use of automake per se has no dependency to coreutils, does it? No. There is any way to obtain the path of one directory relative to another in automake without adding a new dependency? "realpath" implemented as a m4 macro, maybe? Sorry, I'm clueless. Anyone else out there with info? Thanks, Karl
Re: Relative path without realpath
suggests that it can be scripted in portable shell (
So it seems, although:
current="${2:+"$1"}"
target="${2:-"$1"}"
... etc...
all these myriad fancy variable substitutions would have to be replaced
with sed, or something ... --thanks, karl.
Re: ./configure: line 2490: _ACEOF: command not found
./configure: line 2489: Report: command not found ./configure: line 2490: _ACEOF: command not found ./configure: line 2492: syntax error near unexpected token `fi' ./configure: line 2492: `fi' Evidently this is something about this project's configure.in. I don't see it offhand (maybe someone else can). If you send me your generated configure file (best to gzip it to avoid possible corruption), I could try to see what's going on around those lines, i.e., which macro might be going awry. No promises though! --best, karl.
Re: Conditionally overriding variables set by Autoconf
Hi Marius, Makefile.am:86: warning: pkglibdir was already defined in condition TRUE, which includes condition USE_VERSION_LINKS ... All I can think of to do is introduce a new variable in each branch, and define the "built-in" variables outside the conditional. Unfortunately this means reproducing Automake's defaults, as far as I can see. As in this for Makefile.am (and minimal configure.ac below): if USE_VERSION_LINKS mypkglibdir = $(versiondir)$(libdir)/ganeti else mypkglibdir = $(libdir)/@PACKAGE@ endif pkglibdir = $(mypkglibdir) I suspect there is a cleaner way, but I don't have the brains to see what it is. I hope someone else here does ... --best, karl. --- configure.ac --- AC_INIT([amin], [0.0], [nowh...@example.net]) AM_INIT_AUTOMAKE([foreign]) AM_CONDITIONAL([USE_VERSION_LINKS], [false]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT
Re: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
Guess the macro never really worked? AC_CONFIG_AUX_DIR is used in almost every package. For example, Texinfo's configure.ac starts as below. As the comment there says, maybe you were using it after AM_INIT_AUTOMAKE? - AC_INIT([GNU Texinfo], [6.7dev], [bug-texi...@gnu.org]) dnl Must come before AM_INIT_AUTOMAKE. AC_CONFIG_AUX_DIR([build-aux]) dnl tar-ustar because we have long filenames for some test files. dnl parallel-tests as recommended by stefano. AM_INIT_AUTOMAKE([1.14 info-in-builddir parallel-tests readme-alpha tar-ustar]) # Where to generate output; srcdir location. AC_CONFIG_HEADERS([config.h:config.in])dnl Keep filename to 8.3 for MS-DOS. AC_CONFIG_SRCDIR([info/info.c]) - Oddly, I cannot find that necessary ordering mentioned in the documentation. I'm not 100% sure it's always required, either. I'll have to look into that. --thanks, karl.
Re: ./configure: line 2490: _ACEOF: command not found
AC_INIT([wifidog], [1.3.0]) ... AC_INIT(src/common.h) You're calling AC_INIT twice. That doesn't seem like it can be good, althogh I'm not sure it is the cause of the error. (Seems like it would be too easy.) Also: AM_INIT_AUTOMAKE# (wifidog,$WIFIDOG_VERSION) Don't put # comments in the middle of a line for configure.ac. Use "dnl (wifidog...". I got "no valid invocation of AM_INIT_AUTOMAKE found before I removed that. Also, although it should not be related to the bug, I surmise that using AM_INIT_AUTOMAKE([foreign]) would be better, so as to avoid errors about various required files. Anyway, back to the original error: > ./configure: line 2489: Report: command not found > ./configure: line 2490: _ACEOF: command not found .. So, looking around line 2489 of your generated ./configure, I see: test -n "$ac_init_help" && exit $ac_status Report bugs to the package provider. _ACEOF ac_status=$? fi Clearly there is supposed to be some sort of here document there related to the help message. In a normal configure, it looks like this: cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1 ac_cs_usage="\ \`$as_me' instantiates files and other configuration actions ... Report bugs to the package provider." _ACEOF So somehow the beginning of that standard code is not getting output. If removing the second AC_INIT doesn't do it, all I can suggest is chopping stuff out of your configure.ac until you find the piece that causes the problem. E.g., make sure a minimal configure.ac: AC_INIT([amin], [0.0])dnl AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT (and an empty Makefile.am) works, and add stuff to that, or remove stuff from your configure.ac, until you can narrow it down. I was using the original versions of autotools as released by GNU, not the centos versions. So behavior may differ ... Hope this helps somehow, Karl
Re: problems with "make install" directory permissions
https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html I can understand increasing permissions to allow +rx on installation directories, but why force 755, thus disallowing group writability? I've never understood this forcing of 755. I don't think Zack plans to release a new Automake. Jim and I released automake-1.16.2 in March this year. We could make another release, but it seems you have already dealt with it sufficiently. As far as I know, there are no huge outstanding problems in automake. I have been slowly trying to look at the backlog of bugs (since no one else was, for years) and at least apply patches that have been submitted. Tons remain. Of course other active contributors would be most welcome. --thanks, karl.
Re: configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
Hi Tom, Using this: As shown in the Texinfo example, I think the order of the init and config macros is important. Admittedly this is not clearly documented. AC_INIT([... AC_CONFIG_AUX_DIR([... AM_INIT_AUTOMAKE([... AC_CONFIG_HEADERS([... AC_CONFIG_SRCDIR([... Some variations are possible, but not arbitrary rearrangements. The above order should work. I did not see a case where you were trying that. Is the syntax written like this for compatibility reasons with other shells? Yes. Automake (Autoconf too, and plenty more) has to work with any /bin/sh. It long predates POSIX shells and cannot assume POSIX, let alone bash. (For one thing, Solaris /bin/sh is still non-POSIX, as far as I know.) Almost all shell code in other GNU packages tries to be maximally portable, too. Code snippet: # FIXME: To remove some day. Well, I didn't write that comment and don't agree with it :). "x$host_alias" != x; I know adding 'x' or another character prevents failures when a variable is empty but that's been deprecated for sometime. I don't agree with "deprecated". [] is deprecated in favor of [[]] I don't agree with "deprecated". Also, single and double brackets are two quite different things. Double brackets must not be used by shell code that needs to be portable; they're a bash/etc. extension. `` is deprecated in favor of $() I don't agree with "deprecated". Left quotes must continue to work forever and there is every reason to use them, in shell code that must be maximally portable. [] also return false positives allowing conditions to execute in cases where they shouldn't. Have to see an example. I am fairly certain that [...] does not have actual bugs in this regard, barring some truly obscure systems. It is certainly possible to get unexpected results when not used properly. See "test" in the node https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins Not sure about test though. test and [ are synonyms. Maximally portable code should use test, however, because of old os's which could misparse [ ... ] when the ... contained another ]. See the (long) chapter in the Autoconf manual about shell portability for the basis of most of the shell usage in autotools. (The previous url is one ) https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Portable-Shell.html#Portable-Shell Best, Karl
Re: Prepending '+' to the recipe line when linking with GCC's -flto=jobserver
Hi - sorry for the absurdly delayed reply. Almost a year ago, you wrote to this list about prepending a + to link lines: Date: Tue, 18 Feb 2020 16:47:05 +0100 From: "R. Diez" To: automake@gnu.org Subject: Prepending '+' to the recipe line when linking with GCC's -flto=jobserver I am developing firmware similar to this one: https://github.com/rdiez/JtagDue ... https://lists.gnu.org/archive/html/automake/2020-02/msg00012.html I admit I am not immediately sure how to approach this. Precedents are not coming to mind. Some sort of flag in Makefile.am that Automake recognizes and then adds the +, I guess. Jim, wdyt? At any rate, it would be extremely helpful to have a minimal-as-possible runnable (automake-able) example showing the case where the + needs to be prepended. rdiez, can you create such a mini-project? If you have time to do that, please send it to bug-autom...@gnu.org, since that's more trackable than this list. Thanks, Karl
Re: Build and test failures with Autoconf 2.70
They all appear to be cases of autoconf and/or aclocal getting run when the test suite does not expect them to be run. I am stumped as to why In short: because the 2.70 autom4te decided not to update configure. I don't know why not, but I have a guess: maybe the new autom4te ignores everything after AC_OUTPUT. Is that correct? Because that is where some of these tests are adding a new AC_ macro. In long: I focused on the libobj-basic test since it was simpler than the distcheck-* tests. That test ends with a common sequence. First append to configure.ac to test an additional case: cat configure.proto - > configure.ac < libobj-basic.sh Description: Binary data a69ok-libobj-basic.log.gz Description: Binary data a70fail-libobj-basic.log.gz Description: Binary data
Re: Build and test failures with Autoconf 2.70
The attached patch fixes two of the problems: Thanks, I pushed that. There are still four testsuite failures on my dev box, After applying your patch, running make -j12 check against autoconf 2.70, I get those failures and several more (as in your case, they don't appear with 2.69): FAIL: t/distcheck-missing-m4.sh FAIL: t/distcheck-outdated-m4.sh FAIL: t/libobj-basic.sh FAIL: t/remake-not-after-make-dist.sh FAIL: t/vala-non-recursive-setup.sh FAIL: t/distcheck-missing-m4 FAIL: t/distcheck-outdated-m4 FAIL: t/libobj-basic FAIL: t/remake-not-after-make-dist FAIL: t/vala-non-recursive-setup (Perhaps there are new nondeterministic failures with parallel make.) Sigh. I'll investigate when I can, time permitting, but if by chance anyone else is willing to look into it, please do. Thanks, Karl
Re: Build and test failures with Autoconf 2.70
FAIL: t/distcheck-missing-m4.sh FAIL: t/distcheck-outdated-m4.sh FAIL: t/libobj-basic.sh FAIL: t/remake-not-after-make-dist.sh FAIL: t/vala-non-recursive-setup.sh Whoops, I see the vala test is the only one you didn't also get, the rest are duplicates. Sorry for the noise.
Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake
raise the minimum version requirement for Perl to 5.18.0 Sounds sensible to me, for the reasons you outlined. But, I think it would be wise to give users a way to override the requirement, of course with the caveat "don't blame us if it doesn't work", unless there are true requirements such that nothing at all would work without 5.18.0 -- which seems unlikely (and undesirable, IMHO). 2013 is not that long ago, in autotime. don't know what the Automake maintainers' current release schedule We (I, at least, and I'm pretty sure it's true for Jim too) have no schedule. looks like but I imagine this would be targeted for 1.17.0, I guess we would declare the version making this change as 1.17.0. I don't have any other plans that would involve a new minor version. that happens (ideally at about the same time as the Autoconf release making the same change). Sounds feasible, since it doesn't sound like it will be especially quick (I'm glad). --thanks, karl.
Re: Future plans for Autotools
I'd just like to suggest that in the event of future significant development on a new automake, or a revamped build system in whatever way, that the new system not be called "autoconf" or "automake". It seems inevitable to me that any such new system would have incompatibilities with the old, and this would cause trouble both for the new developers (retaining perfect compatibility is hard and ugly, thus typically does not happen), and existing users (their long-time build scripts would be broken).(*) It would surely be nice for a new system to be "as compatible as possible" with the old, but pretending it is a drop-in replacement seems like it would just lead to bad feelings all around. --best, karl. (*) This already happened with autoconf 2.70, unfortunately. Even the minor incompatibilities it introduced are a significant barrier for some of us (at least me) to adoption. The kinds of rewrites being talked about here would surely have far more compatibility issues.
Re: Future plans for Autotools
I think automake really needs to support this soon. Sounds reasonable to me, but to be clear, Automake will only support things that volunteers care enough about to actually dig into the code and write patches for. New developers/maintainers are needed. As I previously explained(*) / pleaded, Jim and I simply cannot commit the necessary time for substantive development -- we can't even keep up with incoming bug reports and interesting suggestions. --best, karl. (*) https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html So far the response has been nil.
Re: Future plans for Autotools
Hi Yvan - sorry for the delayed reply.
While configure/automale/libtool seem to be designed to work together,
Yes, they were. It seems your major issues are with libtool. I can
(uselessly) sympathize, but unfortunately that's all I can do. Libtool
is currently unmaintained (according to GNU records), so until someone
volunteers to work on it, there will presumably be no further changes to
it. (Maybe you or someone reading this wants to take up the challenge?)
- but when it encounters .la files with incorrect .la files, libtool
adds the incorrect dependencies or options, with no workaround
If you (or anyone) can provide a patch for that specific critical issue
in libtool, it might be possible to somehow make a bug fix release.
- or make them more modular, and better able to work
independently. This is probably more of a documentation / example
code issue than an actual development issue.
I expect you know this, but Automake completely depends on
Autoconf. That's not going to change, in the current reality. OTOH,
using libtool is completely optional. Many auto{make,conf} projects
don't use libtool.
For Automake, and I expect for Autoconf, specific documentation
suggestions are welcome, but I at least can't write anything from
"make them more modular", however much I agree in principle.
There are quite a few "best practices" autotools documents around, some
written by past autotools developers, others by autotools users. Sounds
like you have enough experience that you could write your own useful
addition :).
Best regards,
Karl
Re: Behaviour when using both "--dry-run" and "--always-make" together
Hi Johan, make --dry-run --always-make I'm somehow amazed these two options work together at all. They seem mutually unintelligible. In any case, it's the first time I've heard of this, so I don't have a best (or any) practice to suggest. Sorry. Maybe someone else here has some ideas. I imagine there must be some way to avoid the endless loop, but it's not something I'll ever have time/energy to debug. Any reasonable patch would be welcome, though. --best, karl.
Re: Behaviour when using both "--dry-run" and "--always-make" together
So I beleive the conclusion here is that "--always-make" is not really compatible with autotools at the moment (or perhaps self-referential makefiles in general?) Sounds plausible to me. I'll add a note in the automake manual about this. Can't think of anything else feasible to do. --thanks, karl.
Re: How to prevent distribution of `texinfo.tex`
I imagined an option to specify files that are not distributed by default. Sounds reasonable. Such an option doesn't sound too hard to implement, if you or anyone are up for writing a patch. Unfortunately, I'm not likely to get to it any time soon, if ever :(. --thanks, karl.
Re: How to prevent distribution of `texinfo.tex`
Would it make sense only to include this file if a _TEXINFOS variable e.g. info_TEXINFOS is set in Makefile.am? It sounds sensible, although I admit trying to discern whether any _TEXINFOS var is set anywhere in the source tree is something I've never looked into. So it's nothing I'm going to be implementing in the foreseeable future. I can also imagine unlikely scenarios where one would want texinfo.tex even without a Texinfo manual. Thus having an option to explicitly texinfo.tex (or any other autodist file), as Werner suggested, sounds like a better approach to me. By the way, another possibility would be to change automake --add-missing: allow a secondary option to specify files not to be copied that otherwise would be. Personally I find --add-missing awfully mysterious, anyway. Copy some arbitrary set of files from some unknown set of places, possibly (or not) overwriting what's present in the source? No thanks. And there is no --dry-run option so it's possible to know what will be done. A patch to improve that situation would be welcome. --thanks, karl.
Re: Automake testsuite misuses DejaGnu
DejaGnu has always required a DejaGnu testsuite to be rooted at a "testsuite" directory If something was stated in the documentation, but not enforced by the code, hardly surprising that "non-conformance" is widespread. Anyway, it seems like an unfriendly requirement for users. And even more to incompatibly enforce something now that has not been enforced for previous decades. Why? (Just wondering.) -k
automake bug fixers/developers needed
For about the last year, I've been the main person applying bug fixes to (or at least reading bug reports for) Automake. My pace has been quite slow, but since maintenance was almost completely lacking for some years before that, I've been doing what I could. Mainly, going through the old bug reports and dealing with the "easy" ones, besides trying to handle new ones as best I can. There are still many outstanding bug reports that I have not even read. Unfortunately, I am going to have even less time for Automake for the foreseeable future. I will still do what I can, but it will not be much. Therefore, if you have some automake/perl/shell/make/etc. development skill or interest, and are also interested in Automake maintenance continuing, please volunteer if you can. I recommend starting by looking at the open bug list: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_4 FWIW, I knew essentially nothing about the Automake implementation when I started, and still don't know much. To begin, I read the setup info available in the repository, asked questions of friends and lists when needed, got a build working and did some easy reports (e.g., tweak the manual), and went from there. It all takes considerable time; there is no royal road, as far as I know. Jim Meyering remains the official maintainer of Automake, and rolled out the couple of point releases we did in the last year. (Thanks Jim.) But he has so many other responsibilities that day-to-day maintenance for Automake has to take a back seat. Hence the need for more volunteers to help. Best, Karl P.S. FWIW, in the bug list, I have been marking as "confirmed" the bugs which are real, but which I myself can't or don't want to fix any time soon, for whatever reason. Of course it would be great if anyone else takes any of them up. P.P.S. Of course us volunteers get to choose our own aims and priorities -- I personally have no interest in "automake-ng" or any other major development or change to Automake. My goal was and is to keep the existing program that has served so well for so many years viable and maintained. Retaining compatibility, i.e., not breaking existing Makefile.am/configure.ac's, was and is always my top priority. Again, FWIW.
Re: config.sub/config.guess using nonportable $(...) substitutions
1. $(...) breaks Solaris 10 /bin/sh. 2. Solaris 10 is still supported by the vendor, and people still use it with GNU tools. 3. There is no technical benefit to $(...) in config.*. What's the harm in using `...` a few more years in config.*? Answer, as far as I can see: none. -k
Re: config.sub/config.guess using nonportable $(...) substitutions
At some point, failing to support $(...) is in the same ballpark FWIW, I fully disagree. (Along with, it seems, everyone else except you and Ben.) 1) There is no actual benefit to using $(...) over `...`. It is purely cosmetic. In other scripts, fine. In config.*, no. 2) Using $(...) causes a real-life problem on a real-life system. Talking about # as an analogy is a red herring. # does not cause real-life problem. I just don't understand the overwhelming need to create this problem for ourselves. -k
Re: config.sub/config.guess using nonportable $(...) substitutions
Hi Dmitry, I tried to reach the author of that change [2], but, unfortunately, received no response. Ben's lack of response is no reason not to revert this unportability. After all, one steps down from maintainership in order not to spend time thinking about it any more. Clearly Ben had no technical reason for the change; it only causes problems. I hope you're willing to revert it. As I've written several times before :). Thanks, Karl
Re: Constantly changing libtool
Hi Laurence - sorry, but I can't imagine how to automatically correct version mismatches. The possible problems are both unpredictable and endless, seems to me. Maybe others here have some more useful idea. --best, karl.
Re: bug#45756: Prepending '+' to the recipe line when linking with GCC's -flto=jobserver
Hi Nick - thanks for the reply on this. It all sounds sensible. Finally this issue could also probably be solved by changing GNU make itself: providing another mechanism to keep jobserver fds open in rules. Clearly that would be great. On the Automake side, I just don't have the desire to work on this issue. I'm happy to apply a patch if you or anyone has a reasonable improvement, but I'm not going to come up with it on my own, unfortunately. --thanks, karl.
Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake
I think the right thresholds are 5.10 for absolute minimum and 5.16 for 'we aren't going to test with anything older than this' I appreciate the effort to increase compatibility with old versions. I imagine you could provide Digest::SHA "internally", or test for it as Nick suggested, but I know how much of a pain it is to avoid/check for use of things that have seemingly been around forever. (Comes up all the time in the TeX world.) _Possibly_ we would also want `use open qw(:std :utf8)`, I'm not sure. I feel sure that people have old-but-working Autoconf-related files in other encodings. What would be gained by forcing UTF-8? For that matter, I'm not sure why Autoconf (or Automake) needs to be Unicode-aware at all? Best, Karl
Re: automake 1.16.4 and new PYTHON_PREFIX
I think we need an easy way to set a default for this behaviour from within configure.ac, similar to AC_PREFIX_DEFAULT(), so that the end-user doesn't have to pass a bunch of options to configure just to get the build to work sensibly. I have nothing against the idea, but my immediate goal is more basic: restore the previous behavior without losing the new configure benefits entirely. The current workaround I use is described below. Thanks for sending that code. --best, karl.
RE: automake 1.16.4 and new PYTHON_PREFIX
Ok, I guess we'll have to revert the Python change and make another release. I was worried about the change. But I am not sure of how best to deal with the intended benefits. Joshua, can you please take a look at these reports and advise? https://lists.gnu.org/archive/html/automake/2021-08/msg7.html https://lists.gnu.org/archive/html/automake/2021-08/msg6.html Thanks, Karl
Re: [PATCH v2] automake: add install dep on install-libLTLIBRARIES to all targets
Subject: [PATCH v2] automake: add install dep on install-libLTLIBRARIES to all targets Thanks. Have you run make check? (In practice, make -j12 check or similar.) Always good to make sure nothing old breaks ... -k
Re: automake 1.16.4 and new PYTHON_PREFIX
yf> Would keeping PYTHON_PREFIX but changing its default to the "classical" value be a working solution for this ? Yes, I think we should. And I think I should have been smart enough to realize that changing the default behavior was too risky in the first place. Apologies for that. My thought now is to add yet one more option, like --python-prefix-from-python, to get the new 1.16.4 behavior of using the "computed" sys.* values. Else go back to the previous $prefix-based behavior. Does that sound sensible? A better name for the option? Joshua (or anyone), would you be willing to work on something like by any chance? Would be greatly, greatly, appreciated. I am way overcommitted right now (like all of us, I know ...). please keep the --with-python_prefix Definitely. --thanks, karl.
Re: [PATCH v2] automake: add install dep on install-libLTLIBRARIES to all targets
Hi Jan and all. depending on install-libLTLIBRARIES not just for bin_PROGRAMS, but all PROGRAMS and LTLIBRARIES. I installed your patch (for the record: the thread starts at https://lists.gnu.org/archive/html/automake/2021-08/msg00016.html). Thanks much. (Now, on another and unrelated front ... time to see if I can restore the previous Python dir behavior, retain the new setting with an option, and not break anything new. I sure wish there was someone out there who wanted to devote some real time to Automake maintenance.) Happy hacking, Karl
Re: automake 1.16.4 and new PYTHON_PREFIX
Regarding PYTHON_PREFIX setting in automake, I've pushed a change that (I hope) reverts to the previous behavior of using the usual GNU prefix variables by default. It's attached. The new configure option --with-python-sys-prefix yields the the 1.16.4 behavior of using the sys.* Python values. The --with-python_[exec_]prefix options are still present and unchanged, setting the prefixes explicitly. It would be really fantastic if there could be some testing of this by other people before we push out another problematic release. Jim, could you roll a test release please? --thanks, karl. P.S. Oops, I see the brief description in the change is only supposed to be one line. Well, too bad, not going to adjust now. P.P.S. Although the diff shows nearly every line being changed, in fact most of the changes are about indentation. Unfortunately. But separating the formatting changes from the real changes proved too problematic and time-consuming, and I wanted to end up with a correctly-formatted source (as best I could manage). Sorry. ampy.diff Description: Binary data
Re: generated lex/yacc sources?
Hi Nick, Jan, all, nick> I think all that should be needed is to list the .l (or .y) file in _SOURCES normally Thanks much. I was thinking I should avoid that since the .[ly] are not ultimate sources, but if it works, fine with me. jan> BUILT_SOURCES = foo.y foo.y: foo.cweb somecommands That would be sensible, but I failed to mention the problem with BUILT_SOURCES (sorry): the manual says it only works with the general targets (all, check, install, install-exec). I need something that works with individual targets. I'll give the _SOURCES stuff a whirl. Thanks again. -k
Re: [platform-testers] automake-1.16g snapshot
Redoing the tests with 1.16g I now have 9 failed tests, the testsuite.log is attached. Thanks much for giving it a whirl right away. But are those failures anything new? FAIL: t/fn99subdir FAIL: t/lex-clean-cxx FAIL: t/lex-depend-cxx FAIL: t/test-extensions-empty FAIL: t/subpkg FAIL: t/subpkg2 FAIL: t/subpkg3 FAIL: t/subpkg-yacc FAIL: t/vala-mix2 They don't look like anything that was touched in these small changes since 1.16.4; the only real purpose for the release is to get back to the historical Python directory behavior. At least the lex/yacc stuff hasn't worked with Solaris tools for quite a while. There are a number of open bugs relating to Solaris at https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_3 but no one has come forward to look into them. (They will never make it to the top of my list to work on, sorry to say.) Thanks again, Karl
Re: automake 1.16.4 and new PYTHON_PREFIX
If anyone who weighed in on the Python prefix stuff (or didn't, for that matter) has a chance to try the new pretest at https://meyering.net/automake/automake-1.16g.tar.xz that'd be great. It'd be nice not to have to do another patch-up release. Thanks, Karl
generated lex/yacc sources?
Suppose I want to generate a lex or yacc input file from another file, e.g., a CWEB literate program. Is there a way to tell Automake about this so that the ultimately-generated parser/lexer [.ch] files are saved in srcdir, as happens when [.ly] are direct sources, listed in *_SOURCES? I should know the answer to this, but sadly, I don't. I couldn't find any hints in the manual or sources or online, although that probably only indicates insufficient searching. Thanks for any clues. --karl
rm -f # no more args failure?
Does anyone here use or know of an active system where plain rm -f with no arguments fails? I mean, exits with bad status? We are considering changing Automake to assume this works, although we'd provide for a workaround just in case, something like make RM_F="rm -f nosuchfile" But if there are still active systems where it's a problem, we will probably make no change. Thanks, Karl
Re: rm -f # no more args failure?
bf> I thought that systems deriving from OpenSolaris (e.g. Illumos,
...
However, testing in an empty directory on a system without the
upated ksh93 this looks ok to me:
Bob, what you wrote before (approx. a year ago) is here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42529
Ending with:
Behavior of ksh93 (which has a bug) appears to depend on the PATH
setting so it will behave differently if /usr/xpg4/bin or
/usr/xpg6/bin appear in the path.
Maybe that is why you didn't see the behavior just now?
In any case, if a broken "rm -f" still exists in a free system as late
as last year, it seems premature to me to force this change now.
I grant Moritz's point that the ubiquitious "test -z ... || rm ..."
adds noise when trying to understand Automake recipes, but IMHO that is
not enough reason to induce this incompatibility.
mf> collected here as blockers:
https://debbugs.gnu.org/10828
Thanks. No one active (i.e., me) was aware this was being done, so I
didn't add Bob's report as a blocker when it came in.
I grepped the bug archive for the error message ("Your.*rm.*program")
and didn't see anything other than Bob's, but that could have missed
some.
there's only 3 reports filed from the last 10 years.
Which I see are:
May 2016 - MKS Platform component 9.X - bugs.gnu.org/23563
Dec 2015 - Unixware 7.1.4 - bugs.gnu.org/22074
Jan 2015 - Qnx 6.3.2 - bugs.gnu.org/19692
Looks like Unixware 7.1.4 may still be current, but since there are no
later reports, I guess they're not really using Automake, or set the
necessary envvar, or something. --karl
Re: Wrong order of preprocessor and compiler flags
It seems the basic inconsistency is whether CPPFLAGS is considered a "user variable" or not. In earlier eras, it wasn't, but from your msg, I gather it is now. The GNU standards node about it, that you mentioned, https://www.gnu.org/prep/standards/standards.html#Command-Variables does not clearly state it one way or another. But its example shows CFLAGS after CPPFLAGS. Thus I think a prior step is to write bug-standa...@gnu.org and suggest clarifying the status of CPPFLAGS, its relationship to CFLAGS, etc. We could consider changing automake to follow autoconf even if the GCS is not changed, but it would be better if the GCS were clear. 2. Use AM_CFLAGS CFLAGS AM_CPPFLAGS CPPFLAGS. This is more aligned with current flags grouping, but CFLAGS will not override definitions in AM_CPPFLAGS (less aligned with GNU Standards). It seems wrong (and disastrously backwards-incompatible) to me for CFLAGS not to override AM_everything. Your option 1: 1. Use AM_CFLAGS AM_CPPFLAGS CFLAGS CPPFLAGS. I think this is the best option. As required by GNU Standards, CFLAGS still override all upstream-defined flags. seems like the best option to me too. --thanks, karl.
Re: multiple online manual versions
Hi Mike, https://www.gnu.org/software/automake/manual/index-full.html It looks nice, but the plethora of versions becomes rather an undifferentiated mass. Maybe make each major release its own , as in: Automake 1.16 releases: 1.16* versions Automake 1.15 releases: 1.15* versions Just to break it up a little. Also, some simple intro text seems desirable (edit as you see fit): Below are links to the manual for all released versions of GNU Automake. The current manual is also available separately. And maybe an outro too: Above are links to the manual for all released versions of GNU Automake. Wdyt? i actually regenerated them from scratch rather than extract them Sounds good. The copyright at the bottom says 2020. I don't know if that means gendocs.sh needs updating, or the template, or something on the web site, but something somewhere should be changed to 2022. Can you check? --thanks, karl.
Re: multiple online manual versions
per your request, the default is unchanged. I understand (and thanks), but my question was about the "table" (whether it's actually a or not): * (Feb 2018) GNU Automake 1.16 (HTML PDF) * (Dec 2014) GNU Automake 1.15 (HTML PDF) * (Jun 2013) GNU Automake 1.14 (HTML PDF) On what page were you going to put this table of all available manual versions? BTW I still think it's more useful to have the manual for the latest 1.xx.y release of each 1.xx than the original. Why propagate known-old information in preference to newer? tbh the only reason i'd prefer a table is for the column alignment. Sure. Fine by me. However it works out best. Thanks. -k
Re: multiple online manual versions
* i'm assuming that we don't want to modify lib/gendocs_template since it's synced with upstream gnulib For sure. so the default manual/ landing page & manual will be unchanged from today other than having a link to the full versioned index What url/filename are you thinking for the "full versioned index"? GNU Automake 1.16 ... vs. ... Feb 2018 GNU Automake 1.16 HTML PDF I doubt the old manuals will get a tremendous amount of use, so one line per version seems sufficient to me, vs. a table. But I have no objection either way. OTOH, the date and the direct link to the html seem like the most interesting information (more so than the PDF). Could be something like: GNU Automake 1.16 - Feb 2018 - HTML But I don't feel strongly about it. Whatever seems sensible. It might take seeing the page with a few versions actually done before it's clear what's best. --thanks, karl.
Re: multiple online manual versions
> https://www.gnu.org/software/automake/manual/index-full.html It's better, but how about a non-blank line? (does obey table cells? I'm never sure.) Obviously we're getting down to trivialities, feel free to ignore :). so i guess once gnulib merges my update, If nothing happens soon, let me know and I can commit that update. (I'd do it now but some kind of network problem, apparently at the FSF end ...) --thanks, karl.
Re: multiple online manual versions
i was planning on the full index being maintained here: https://www.gnu.org/software/automake/manual/index-full.html Sounds good. >>See the [full version index] for other versions of the manual. Good. Maybe something like: >>See the [full version index] for the manual for older releases of Automake. (Since it's not just "versions of the manual", but "versions of the software". :) Not sure. Will be easier to think about seeing the pages actually differ and setup symlinks in case the manual didn't change between point releases. I doubt there are significant changes to the manual for most point releases, but still, I think it would be confusing to ask for the manual for 1.16.2 and get the manual for 1.16.1 instead. I think it'd be best to just do the full thing for any versions published. --thanks for all, karl.
Re: multiple online manual versions
Having multiple versions of the manual online sounds all to the good to me. As long as it's being done at all, I wouldn't hesitate to put up the manuals for every release, not just the major releases. For 1.16.x, I'm afraid I rather broke the previous rules for major releases anyway. https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-/ What I don't like about this approach is that it redirects from the generic url to the versioned url. Also, the /savannah-checkouts/ seems pretty ugly. I think it would be cleaner to create and commit /automake/manual-/ for whatever s desired. Could probably get them out of CVS. Then automake/manual/ could remain unchanged, as a copy of the current . FWIW ... --best, karl.
Re: adding a command line option for ACLOCAL_PATH-type search paths
Hi Mike, the ACLOCAL_PATH functionality is useful (adding search dirs after -I), but a bit unwieldy as an env var. any reason we can't add a command line option for this ? Seems like a fine idea to me. call it --aclocal-path ? or --extra-system-acdir ? Reading the doc, my hunch is to call it --aclocal-path and make the semantics of its argument be exactly the same as $ACLOCAL_PATH. Wdyt? But if both are set, should the --aclocal-path argument replace $ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure. By the way, would it be feasible to have --help show the actual values for --automake-acdir and --system-acdir? It is far from obvious. --thanks, karl.
Re: multiple online manual versions
* the current page, but with an entry/link like "For older manuals, please see this index." Agreed this is preferable. Not a fan of the gcc index page. changes to the manual the rename or reorder chapters, we're breaking those historical links. Reordering isn't a problem; that doesn't break links. Renaming nodes is what breaks links. And the answer is, 1) don't do it, and 2) if you feel you simply must, leave an @anchor behind, and then existing links will not be broken. Anyway, the manual hardly changes nowadays, so it's not an issue in practice. To me, the redirection to a versioned url a la autoconf often leads to the wrong behavior in the other direction: typically people want to link or refer to the current version of node Foobar (whatever version it might be), but it's too much trouble to do when you end up getting redirected. So it doesn't happen, and then X years now people still think autoconf-2.68, for example, is current because that's what the link say. (Rather like bugs.gnu.org/ being preferred, but since that redirects, hardly anyone uses it and it's just manual labor to do so. But I digress.) any other manual/ access would redirect to the latest version. that way we don't break links already out in the wild. Agreed we certainly must not break existing links. But I'd rather have a copy as the unversioned/canonical page than forced redirection in all cases. Both canonical and versioned urls are useful. https://www.gnu.org/software/automake/manual/1.15/ https://www.gnu.org/software/automake/manual/1.16/ (or if you prefer, 1.15.x and such) If not publishing all versions, it would seem better to me to publish the latest version of the manual for any given 1.x, not the first version. I.e., 1.13.4, 1.14.1, 1.15.1, 1.16.5. I don't see that there's anything especially magical about the "non-dot" releases like 1.15, although I have no objection to publishing those too. --thanks, karl.
Re: community long term x.y release branches
i would like to help coordinate these downstream distros so they don't have to keep all repeating the same work. basically: Sounds sensible to me. * commits are on a volunteer/request basis -- there is no expectation that people working on master/whatever think about these older branches I like that in particular :). * maybe we cut a new release once a year from those branches if any changes were actually made to them. i would like this, but even if we do all the other things above and omit this, i'd still be happy. Sounds reasonable, not that I'd be the one making such releases. I'm guessing Jim would want to push making such "back releases" to you ... so since the last release is still 1.16.z, the newest such branch would be refs/heads/release/1.15 and it would start life at v1.15.1. Fine by me. Jim, can you chime in? As you know, I have little clue about git development conventions, so can't make any sensible comments at that level. BTW, the next release will surely be 1.17. Some of the stuff I already did in the 1.16.x releases really should have provoked 1.17, but I just didn't adhere strictly to the rules (because I didn't know about them). --thanks, karl.
Re: armflang: error: unknown argument: '-soname'
Hi Anton - thanks for the report. https://github.com/HDFGroup/hdf5/issues/366 with the solution that "-Wl," must be prepended somehow to "-soname". Why do you think this is not a libtool issue? Isn't it libtool's job to figure out the arguments that need to be passed? The fact that the -Wl is provided for gfortran and not for armflang makes me think even more that it is libtool. At first glance, the string "soname" does not appear in the Automake sources. But I'm not sure what changes I need to do to my configure.ac and/or Makefile.am to fix this correctly. I wish I had a workaround for you, but I just don't know the answer. Someone else here probably knows better, else I suggest posting to bug-libt...@gnu.org, ideally with a reproducible case. Happy linking, Karl
Re: armflang: error: unknown argument: '-soname'
While libtool has a new maintainer (Alex Ameen), essentially nothing happens, which is quite unfortunate... 1) libtool 2.4.7 was released in March 2022 (I don't know if Alex did it), which isn't so terribly long ago. Sure, maintainers should at least confirm bug reports and patches, even if releases don't happen quickly (pace my own efforts with automake), but ... 2) When a package appears to be unmaintained, the first thing to do is simply write the maintainer to see what the story is. If there is no response, the next step is to write maintain...@gnu.org. It's their responsibility to make continued efforts to contact the maintainer, up to and including sending paper mail. And look for a new maintainer if need be. 3) If that also fails, the final fallback is to write gnu-advis...@gnu.org and/or r...@gnu.org. Best, Karl
Re: How to speed up 'automake'
Fancy doing it? Jim agreed :) Yeah, sorry. Other priority things have intervened :(. I have a mild hope of getting to it by tomorrow. If someone else wants to make the commit, certainly fine by me :). -k
Re: How to speed up 'automake'
I was going to bisect but if it doesn't fail for me in the first place... :( Thanks. Indeed, reconfiguring etc. got rid of those errors. Now a bunch (12) of the Python tests are failing for me, presumably because of previous Python changes not playing nicely with my older Python version (2.7.5 on CentOS 7). Sigh. Not looking forward to figuring that out. Anyway, that's surely independent of empty dependency files, so I pushed Jan's change. Thanks! --karl
Re: How to speed up 'automake'
Unrelated to Jan's depend.am change, but it turns out that a previous change broke make distcheck (768 failures). I don't feel right about committing anything else until that is fixed. Error below. Jim (or anyone), can you easily advise? I haven't delved into this part of things before. (Not sure how many of the failures are due to these errors, but I suspect most.) --thanks,karl. FAIL: contrib/t/multilib .. configure.ac:4: warning: _AM_PROG_RM_F is m4_require'd but not m4_defun'd aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... configure.ac:4: the top level configure.ac:4: warning: _AM_PROG_XARGS_N is m4_require'd but not m4_defun'd aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... configure.ac:4: the top level configure:2411: error: possibly undefined macro: _AM_PROG_RM_F If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:2412: error: possibly undefined macro: _AM_PROG_XARGS_N
Re: How to speed up 'automake'
automake --verbose --warnings=all --add-missing --copy Since you're talking about cron, I'm guessing the terminal output is being redirected to a file? Because if it's going to an actual tty, that can consume a surprising amount of time. Is there a way to speed 'automake' up? Only real idea I have is to run automake under the Perl profiler and see what comes up. As in, install Devel::NYTProf from CPAN and then run perl -d:NYTProf /path/to/automake/executable Best, Karl
Re: How to speed up 'automake'
- @echo '# dummy' >$@-t && $(am__mv) $@-t $@ + @: >>$@ 1) does it actually speed anything up? 2) without the mv I fear we are no longer noticing write failure. -k
Re: How to speed up 'automake'
I see no reason why mv would be so crucial. Hmm, I guess you're right. Thanks for the analysis. The purpose of the stamp files is to avoid partial files being written (and screwing up future makes), but if the file is zero bytes, it seems that problem cannot happen. Jim, do you agree? I'll install the change if yes. --thanks, karl.
Re: man_MANS install locations
Hi Jan, As for GNU/Linux, what was the rationale to only permit [0-9ln]? No idea. Maybe just didn't think about "m", or maybe it didn't exist at that time? Jim, Paul, anyone? Should automake be relaxed? I see no harm in allowing more (any) letters, if that's what you mean. When running automake on Solaris, placing svcadm.1m into man1 rather than man1m seems outright wrong. But is Automake's purpose to reproduce platform-specific behavior, or to have consistent behavior across platforms? I think the latter. I guess a new option to install *.1m in man1m/, etc., would be ok, if you want it. If you or anyone can provide a patch, that would be great. Unfortunately I doubt it's anything I will ever implement myself. Should the rpmlint check be adjusted to cater to the GNU FHS? I guess that's a question for the rpmlint people, whoever they are. I don't see that Automake's default behavior is going to change. Also, GNU (as an organization) never had anything to do with the FHS, so far as I know. I don't think the GNU coding standards/maintainer information have anything to say about this topic ... --thanks, karl.
Re: python debugging on trunk
The appended patch should address both issues. Thanks Zack!! I installed the changes (separately). Note that I have only tested it with Python 2.7 and 3.6. It _may_ not be correct for Python in the 3.0--3.3 (inclusive) range I didn't test any of those versions either. Certainly your change is a vast improvement in any case. The test suite now passes on my Alma Linux 8 system (I had one unrelated failure which I could now fix). For the record, this has Python 2.7.18 and 3.9.7. Thanks again! -k
python debugging on trunk
Is anyone up for debugging some Python-related test failures on RHEL-based systems? Mike Vapier from gentoo made many improvements to the Python support. (Mike, if you're still out there, would love to hear back.) Unfortunately, the end result is that 13 tests (listed below) now fail for me on Alma Linux 8 (and, presumably, Rocky 8; and I believe CentOS 7) with the trunk automake. My appetite for (and experience in) debugging Python problems is pretty low. But we can't make another release until this is fixed. So, I wonder if there's anyone else who's interested in figuring this out. I can probably figure out access to a system where it fails, if that's a problem. I have a suspicion the problem is that on RHEL systems, "python" invokes "python2" (because that's what the Python maintainers recommend, as I understand it), but the tests are assuming it invokes "python3". Knowing Python, I feel pretty sure that there will be many complications in dealing with this. Thanks, Karl FAIL: t/instmany-python.sh FAIL: t/nobase-python.sh FAIL: t/py-compile-basic.sh FAIL: t/py-compile-basedir.sh FAIL: t/py-compile-destdir.sh FAIL: t/py-compile-option-terminate.sh FAIL: t/python3.sh FAIL: t/python12.sh FAIL: t/python-prefix.sh FAIL: t/python-pr10995.sh FAIL: t/python-vars.sh FAIL: t/subobj-pr13928-more-langs.sh For example, test-suite.log shows this for the nobase-python.sh failure: .. Byte-compiling python modules... one.py Traceback (most recent call last): File "", line 13, in AttributeError: 'module' object has no attribute 'implementation' make: *** [Makefile:304: install-myPYTHON] Error 1
