Having something that works with any 3rd-party project is difficult,
I thought you were talking about your own projects. Since no one but
you has ever asked for this, as far as I can recall, evidently the rest
of the world is not in dire need of this feature. It's been a problem
since day on
Hi Vincent,
This requires manual setup *each time* "automake --add-missing" needs
to be used.
Well, or writing a tiny script to do whatever you want to do. That's the
real solution, it seems to me.
For texinfo.tex in particular, you could possibly use the TEXINFO_TEX
variable, as I wrote
"kpsewhich texinfo.tex" seems to be a way to get the correct path.
Sometimes, but sometimes not, as I said.
Then automake should have a way to pick them.
It already does, seems to me. Put the file you want in place before the
--add-missing run, using whatever method you want, and automak
but what about a mode where it retrieves the latest version of
each file that is frequently updated, directly from its official VCS
source?
It's useful, but seems far from Automake's core purpose. It seems better
to me as a separate script than as part of Automake.
And that script has
Hi Vincent. As far as I know, --add-missing has never checked for
whether its versions are older. I don't know of a reasonable way to
change this -- it's a common problem, and also inevitable, given
asynchronous releases of everything involved. Instead, it doesn't
install over existing files.
I b
Hi Eric,
Three of those appear to be in the t/tap-stderr-prefix tests and the
other for t/yacc-bison-skeleton. A gzipped version of
test-suite.log, trimmed to the output for the four unexpected
failures, is attached.
Thanks for the report. I'll look into it as soon as I can, if n
Hi Richard,
I did not see any mention of this issue in the manual or existing bug
reports. Please let me know if I overlooked something.
Pretty sure you haven't overlooked anything. Don't recall seeing
any mention of this before.
I will send a patch adding test cases as soon as I k
Hi Jelle - thanks for the report.
The owner/guid could be set --owner=root:0 --group=root:0
OK.
and to get rid of the timestamp --mtime='@0' (Or alternatively a fixed
timestamp which can be set via SOURCE_DATE_EPOCH).
Do you have a specific suggestion for how to use SOURCE_DATE_E
The following seems -- as verified by some casual testing -- to do
what I want:
Yay! Your code looks nice.
Should I attempt to write a patch documenting this workaround or is
this too niche of a problem?
A patch for the documentation would be welcome, sure. Don't worry about
exac
Sure. Here is a tree for a minimal project (see also the attached archive):
Thanks much, Marc. That's very helpful. Will look into it as soon as I
have a chance (if no one else gets there earlier). --all the best, karl.
Hi Marc,
At least in connection with the Automake running in silent mode, the
check-DEJAGNU target should produce no noise in the output.
Thanks for the message. Sounds sensible to me, for silent mode. Do you
have a sample Makefile.am/configure.ac? It would help me not to have to
constr
if DISTRIBUTE_CHANGELOG
ChangeLog:
echo nop
endif
I haven't had a chance to test this, but how about making the conditional
merely define a variable, and a fallback ChangeLog rule, as in:
if DISTRIBUTE_CHANGELOG
ChangeLog_target = ChangeLog
else
ChangeLog_target = no_Chang
Thanks for the report and looking into the code. There have been
previous reports relating to targets and conditionals, e.g.,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13940 (from 2013 ...)
and I think it's been mentioned in mail and elsewhere, too.
Updating the doc is no problem, thanks. But
Works for me, but don't we need to change the GNU coding standards to do
even that?
To my eyes, the coding standards only prescribe the existence of the
various dvi targets and variables. They don't say that making dvi is a
dependency of either check or installcheck. The distcheck target
What kind of problems would attempting to build the DVI or PDF manual
really catch these days, which aren't already triggered by attempting to
make the *.info manual?
Building dvi/pdf definitely has a chance of catching errors,
since it's a complete different Texinfo implementation (te
The Standards reference
- Makefile targets 'dvi' and 'install-dvi',
- a variable 'dvidir',
- a configure option --dvidir.
All of these would have to be removed.
Although I have no particular initial objection to removing the dvi
stuff from standards.texi, I wouldn't want
Hi Bill - thanks much for the detailed and thought-out message.
Since the same source would
be compiled for multiple devices, it would be advantageous to compile
the source with multiple compilers within a single Makefile.am.
...
add new variables (`maude_CC', `maude_CXX',
The Solaris failure is because their date does not support the '--date'
or '-r' option.
As far as I can tell, the date command on Solaris 10 (cfarm210) and 11
(cfarm211) does not support any way to print a specified date value. So
I inserted a fallback to perl -e 'print scalar
gmtime($SOU
Does anyone have a BSD system (any flavor) I could get access to?
Alternatively, attached is my unreleased version of mdate-sh which tries
to handle SOURCE_DATE_EPOCH. It seems to work ok with GNU date. I copied
the BSD date command (date -u -r ...) from
https://reproducible-builds.org/docs/source
Hi Nick, Yang,
IFS=$' \t\n' is a bashism which is not supported in most other shells.
The original code is portable. This seems to have nothing to do with
the rest of your change, so why change it at all?
Indeed, I was going to make the same comment. I won't be installing that
part o
If you need to link against libraries that are not found by
@command{configure}, you can use @code{LDADD} to do so. This variable is
-used to specify additional objects or libraries to link with; it is
-inappropriate for specifying specific linker flags; you should use
-@code
Hi,
Subject: bug#78329: bash extraction of segment from end of string
returns full string
Thanks for the report, but why are you sending this to bug-automake?
It seems like bug-b...@gnu.org is the right list for this one ... --best, karl.
Hi Ross - I tried to again to reproduce your AC_RUN_LOG leftover after
autoreconf, following your original report at
https://lists.gnu.org/archive/html/automake/2025-02/msg00037.html
and followups over the last couple of months.
Downloaded intltool from https://launchpad.net/intltool/+download
a
-The '--test-name', '-log-file' and '--trs-file' options are mandatory.
+The '--test-name', '--log-file' and '--trs-file' options are mandatory.
Thanks Reuben. I installed it. -k
Sam, if your situation needs to remove .deps at make clean, how about:
clean-local:
rm -rf .deps
It does not seem plausible to me to change automake's behavior in this
regard at this late date. It would surely cause a lot of trouble in a
lot of packages. --best, karl.
Hi Ross,
I shall update to the final [autoconf] release
Have you had a chance to try this? I would like to get to the bottom of
this so I can make the release.
because intltool is already configured, being a tarball.
Your intltool link does not seem to provide any tarball.
[1] a
A patch to mdate-sh might take the form of checking (possibly only
when a command-line option is also specified) if $SOURCE_DATE_EPOCH
is set in the environment, and if so favoring that timestamp over
the mdate of its target file.
That sounds doable. Thanks. I don't think an extra
-# developer- defined test setup AM_TESTS_ENVIRONMENT (if any), and
+# developer-defined test setup AM_TESTS_ENVIRONMENT (if any), and
Thanks Reuben. I applied it. -k
I renamed find_file to find_file_with_opt
Thanks.
I would prefer to rename the original function to find_file_m4
I agree in the abstract, but it's not worth creating an incompatibility.
Look, the last argument *was* described:
Yes, I saw that, but a few words in the description wo
Is there a way to get more visibility into what autom4te is doing?
autom4te --help lists various options (at a glance: --verbose, --debug,
--trace=AM_TRY_LOG, who knows what else). I've never actually understood
autom4te in the slightest, sorry to say. Maybe best to bring it up on
bug-autoc...
Hi Eric and all,
eb> now questioning why Debian ever needed a patch to rip UPDATED out of
eb> the manual in the name of reproducibility.
Me too.
If the mtime isn't changed, then the original UPDATED should be
unchanged, and there's no problem.
If the mtime is intentionally changed by a patch or
Hi Ross - continuing on bug-automake from your report at
https://lists.gnu.org/archive/html/automake/2025-04/msg2.html.
(No reason to bother platform-testers with this.)
> I repeated my tests and rebuilds of existing source trees that have
> been configured with 1.70 still break for me
Hi Eric and all,
mdate-sh was older at the time 1.4.19
was cut; it has changed in the meantime
The only changes to mdate-sh in recent years have been trivialities
involving the help message and induced Emacs incompatibilities for the
Local Variables block. The actual code hasn't changed i
Hi Santiago - back on:
aclocal: error: too many loops
aclocal: Please contact .
at /usr/share/automake-1.16/Automake/Channels.pm line 655.
I still don't know how to improve the error message, but in response to
the same bug report with another package (#77395), I found that in the
p
Thanks for the patch, and sorry for the delayed reply. My concerns are:
1. Changing the meaning of the --libdir option so that it adds rather
than replaces. We have no way of knowing if existing projects rely on
that, but it's quite possible. A new option name is needed to avoid
breaking compatibi
at /usr/share/automake-1.17/Automake/Channels.pm line 658.
Automake::Channels::msg("automake", "", "too many loops")
Thanks for the report.
The full reproducer is this:
Thanks.
Is this issue known?
It was also reported for current Alpine, but not in a way I coul
Hi Nikolaos - thanks for the submission and the reversion :). I find
the existing text (and the companion suffix7.sh test) quite confusing,
but it does seem to be written as intended. So, closing.
Regarding the question you sent me separately, about still looking for
maintainers: most definitely.
Hi Eric and all - back on this report from 2015 (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20831
This is a regression in behavior in upstream automake. It means
that any automake-generated file that is unpacked with timestamp skew
will now fail to build
Yes. I'm afra
Hi Javier - back in 2011 (!), you suggested switching to ustar as the
default tar format for Automake. Sorry for the absurdly late reply. This
has now been done for the upcoming automake-1.18; see discussion in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74847.
As I guess you know, both then and
Hi Pavel - back in 2014 (!), you suggested supporting python2 and python3
simultaneously: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17811
Essentially by defining a new "python3" primary to sit alongside
"python".
Agreed that this is desirable in general. It's now being discussed in
https://d
Hi Florent - you sent in a report about automake gratuitously finding
install.sh in a parent directory back in 2015 (!). Sorry.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19964
You probably have reasons to look in .. or ../.. (and I would be
quite interested to hear them, actually)
Back on this suggestion:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74847
What do you think about changing Automake's default tar format from v7
to ustar?
Given Bruno's experience, ok, let's try. I won't be surprised if
problems come out of the woodwork, but maybe it will be fi
Thanks for the report, Reuben. I'll mark it as confirmed+needs help, so
it can stay open and people looking for something stray to work on might
find it. Like you, I'm content for it to stay open until there is
further demand. --best, karl.
The attached patch assumes that
"no-dist-built-sources" is the right option name
Yes, good. I played around with the test some more for cleanliness, but
didn't touch your changes to the code. Hopefully "no-dist-built-sources"
now operates as intended. Pushed and closing ... thanks Bogdan.
I'm closing this for lack of information, but feel free to reply/reopen
or open a new issue if desired. --thanks, karl.
[I mailed this yesterday, but the bug has not been updated. Disturbing.
originally mailed on Date: Sun, 23 Feb 2025 13:35:17 -0800.
Trying again.]
Hi Giacomo - back on your report from last year (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73316
1. As you pointed out, TAR_O
I'm going to close this for lack of any apparent way forward, but feel
free to reply/reopen or open a new issue if desired. --thanks, karl.
Hi Giacomo - back on your report from last year (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73316
1. As you pointed out, TAR_OPTIONS is working fine from the command
line, but it doesn't work when written inside Makefile.am,
You need to add an "export" directive to t
Hi Maxim - I think so much depends on the details of a given project
that I lack ideas for something to do in general.
One possibility that occurs to me in your case is to turn your automake
conditional into a make conditional, instead of mixing them.
Another possibility might be to move the make
configure generated by autoreconf includes
this line:
AM_DEFAULT_VERBOSITY=0ac_config_headers="$ac_config_headers config.h"
Thanks for the report and proposed fix, Francis. I added Nick's suggested
m4_newline() to AM_SILENT_RULES in silent.m4.
I see in your kea configure.ac:
m4_ifd
I need to install automake-1.9 on macOS Sequoia 15.3.1
Automake 1.9 was released in 2004. I'll be surprised if it works on the
latest mac.
In any case, you'll need to replace config.sub, and perhaps other such
common files, with the latest versions, after unpacking. You can
download the lates
the three patches from the preceding mail are ready to commit.
Thanks very much for all your work (and explanations) on this, Bruno.
Committed. -k
Hi Kirill - thanks for the report and proposed fix.
export MSYS2_ARG_CONV_EXCL='-Tp'
Setting an environment variable seems fairly safe, since if an older
version of the compiler doesn't pay attention to it, at least the
problem will not become worse.
However, I'd like to hear from others who
GNU Automake will generate a broken Makefile when configuring if
some variables containing line breaks.
Thanks for the report. I'm not sure what Automake can do about it,
though. It's just doing what it's been told, seems to me?
Admittedly the error message is less than ideal, although th
Hi Santiago,
at /usr/share/automake-1.16/Automake/Channels.pm line 655.
The current version of Automake is 1.17. Hopefully you can try against
that. I seem to remember some sort of bug relating to that "too many
loops" error, but who knows.
apt-get source alpine
cd alpine-2.26+dfsg
>> Possibly automake can move from v7 to ustar.
Possibly. What's the advantage? --thanks, karl.
Hi Collin - looks fine to me. Applied. Thank you for updating the
timestamps and providing the ChangeLog entry. --happy hacking, karl.
>./configure PERL='/usr/bin/env perl'
>
> and it will substitute that into the scripts for you, but the configure
> script in Automake 1.17 exits with a fatal error if it determines that
> $PERL contains spaces. We should probably make this non fatal since the
> check i
Should we open a bug for this?
No need to open a separate bug. I can change AC_MSG_ERROR to
AC_MSG_WARN, and perhaps tweak the message a little. --thanks, karl.
Hi Maxim,
the Make conditionals would not work as I expected.
Since Automake rearranges things quite a lot when generating the
Makefile from Makefile.am, I'm not too surprised there can be problems.
I could give it another look to see if I
can distill some interesting points from t
Hi Maxim - thanks for the report and doing the research to find that old
answer. Do you have any ideas for a better solution? I can't think of
one. We can't change Automake syntax now. Nor does it seem maintainble
for automake to have special knowledge of all of make's builtin
conditionals and matc
without this being a factor 0 fails 0 errors, sorry for the false alarm :)
Thanks Jeff. Those are the kind of problems I like :). Closing ...
Hi Jeff,
automake: 1.17 "make -k check" (-j8) told me to email my test results
here so here they are
Thanks for the report. Looking at the log, the two failures both seem to
relate to the version of autoconf changing during the run, which seems
bizarre. I can't think of anything Automake
ments. I.e., it does not apply to a C<+=> assignment (except
when part of it is being done as a conditional C<=> assignment).
-This function will all run any hook registered with the C
+This function will run any hook registered with the C
function.
=cut
Running comma
Hi Giacomo - thanks for the report. Unfortunately, I (still) don't see a
good way for Automake can automatically deal with this problem. After
reading the various links in your message, it seems even less feasible.
Automatically switching to tar-pax if the current id is too large feels
like too bi
Hi Eric - I've just committed a change that I hope fixes the version
number problem. (See https://bugs.gnu.org/72157)
However, looking at your list of failures, I see that some of them are
still about *.dSYM, now relating to distclean. E.g.,
t/yacc-bison-skeleton-cxx.sh shows:
ERROR: files lef
Hi Dario - thanks for the report. I've made the changes below to try to
support the new four-part numeric version numbers, like 1.17.0.91 (which
is now the current dev version).
All the tests pass for me, so I hope it's also usable. I won't be
surprised if something is still messed up somewhere,
Hi Eric - thanks for the follow-up. I believe most or all of those
failures are because of a dumb automake version parsing problem that I
haven't fixed yet (there's never been a version like 1.16.0.90 before),
unrelated to the .dSYM patch.
BTW, I ran my make check with -j too. It's pretty unbearab
Hi Eric - I applied the patch from 72225, which hopefully also fixes
your report in 72852. Closing both, with fingers crossed. Thanks!! -k
Hi Eric,
Subject: bug#72852: Testsuite summary for GNU Automake 1.17 on
x86_64-apple-darwin20.6.0
Thanks for the report. It looks like Apple's compiler, or linker, or
something, is leaving new files, in fact a whole new directory, behind.
I didn't check all the failures, but the ones I l
> - $output_rules .= "check-am: all-am\n";
> + $output_rules .= "check-am: all-am";
> if (@check)
> {
> - pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t ",
@check);
> + $output_rules .= " @check";
Looking again, the
Thanks much, Bogdan.
-recheck: all %CHECK_DEPS%
+recheck: all-am %CHECK_DEPS%
Do you have a grip on all-am? Looking at handle_all in bin/automake, I
admit I remain baffled as to what all those pieces of all-am are, and
why it's done as it is.
- $output_rules .= "check-am: all-am\n";
Thanks Bogdan! I will review as soon as I have a chance. --best, karl.
nb> there must be an expansion written somewhere in configure.ac
which is producing the problematic construct.
Thanks Nick.
Francis, can you show us your configure.ac please?
But at the same time, it is probably not a big deal to restore the
extra newline in Automake. But maybe
AM_DEFAULT_VERBOSITY=0ac_config_headers="$ac_config_headers config.h"
Thank you very much for the report and patch (which looks perfectly
reasonable at first blush). I am surprised there's no test for this so
that it would have been caught before the release. I'll look into it as
soon as I hav
Automake installed from the current master (commit
4e6eff3597649782def55fc1dfeeec92cec4b15e) is unusable:
Thanks for the report. Will look into it asap. Hopefully someone else
(Bogdan?) will beat me to it. --best, karl.
I've committed the changes below to help give more hints about the need
to run libtoolize. I ended up adding a new section to the manual and
referring to it from the alpha-NEWS and variable warning. It's in the
below patch as the new
@node Libtool library used but LIBTOOL is undefined
After maki
While I agree I can avoid this problem with the acinclude.m4
approach, I'm hesitant to do so because it's a corner case we don't
hit that often, I'd rather put my effort into a general fix for
everyone.
I understand. OTOH, I can say that putting Nick's m4 magic into your
acinclude.
slow every bootstrap for us (which we do frequently) to work around a
relatively rare issue.
Nick's solution of using acinclude.m4 seems ideal. But just in case: I
think you could also avoid the extra libtoolize calls by doing them only
if the automake --version is x.y.9*, i.e., a test rel
libtoolize: linking file `sntp/m4/libtool.m4'
Indeed, that seems like it should work, because the aclocal invocation
from autoreconf is looking into sntp/m4 (and /m4 too) and
finds other files there:
..
autoreconf: running: aclocal --verbose --verbose -I sntp/m4 -I sntp/libevent/m4
-I sntp/l
> But none of this is meant to suggest that there isn't actually some real
> change in aclocal behaviour which is causing the results you are seeing.
I've failed to find any regression. As I said, if I install 1.16.5 into
a test --prefix and run ntp's bootstrap with that prefix, it cannot
Hi Dave,
Why is it installing prerelease automake in a different prefix for
testing hasn't required also installing libtool to the same prefix
In general, I think it does. And always has. This is not new behavior,
as far as I can see.
(think back to your "baffled" comment)?
Indeed :
Hi Dave,
# wget https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz
# tar xf *p18-vcs*xz
# cd *vcs
# ./bootstrap
After more testing, I don't believe it is a regression. If I install
1.16.5 in its own prefix, say /tmp/am165, the ntp bootstrap fails in the
same way:
Makefile.am:16
Repro steps
Thanks. Evidently something must have changed in automake's libtool
support, but looking at the ChangeLog, I don't see it. I will look into
it ... --thanks, karl.
Hi Dave,
installed and installing the prerelease version to a prefix earlier on my
$PATH, not realizing I also needed to install libtool to the same prefix
Well, I'm glad that it's apparently not a "real" problem, but I'm rather
baffled. When I test an automake pretest, I don't do anythi
I've attached a patch that I think handles that
Thanks Collin. I installed it (with minor wording tweaks).
and the extra space you mentioned.
I had thought the extra space was useful rather than confusing,
indicating that a word had been omitted from the output. But I'm fine
with leavin
Here is a patch that allows the package maintainer to eliminate the
SKIPped test logs, thus making test-suite.log more useful: either
by running
make check IGNORE_SKIPPED_LOGS=1
or by defining in the Makefile (or Makefile.am):
IGNORE_SKIPPED_LOGS = 1
Thanks Bruno. I ins
When Paul fixed typos in various files a few days ago:
commit 1d35638b23e95fe6f41c828a3442f6d7f242f4c4
Author: Paul Eggert
AuthorDate: Fri Jun 7 08:41:45 2024 -0700
maint: spelling and whitespace fixes
He noted:
* t/instdir-ltlib.sh: Fix misspellings of macro names.
Hi Yves - back in 2017 you sent a patch to sort keys in automake:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25629
Attached is a patch that I believe fixes any remaining uses of
unsorted keys.
I've now applied this, with the exception of
a) the cases that had already been done in t
Is bug-automake working now?
Do color-tests2.sh and color-tests2-w.sh both write to the same
directory and, thus, running in parallel may have caused them to be
writing to the same file(s) at the same time?
Every test runs in its own t/*.dir/ directory. The ct2-w.sh test
sources the ct2.sh shell script, but it's
Hi Erik,
* color-tests2.sh and color-tests2-w.sh fail -- logs attached.
Is this with the old make 3.81 from the system, or the new make you
compiled? What is in the "stdout" file in t/color-tests2.dir/stdout?
And, are these the only two tests that fail in the entire suite?
What I see in the
* fine on the tests that failed previously because of macOS default
make having only second resolution
Great! Thanks much for the instant testing.
* color-tests2.sh and color-tests2-w.sh fail -- logs attached.
I had tweaked some of the color stuff, so I must have messed up
somewher
1 - 100 of 489 matches
Mail list logo
