On 21 Jan 2024 14:42, Karl Berry wrote:
> I changed the pretest version to 1.16.90. Closing.
thx bud. i appreciates you.
-mike
signature.asc
Description: PGP signature
On 17 Jan 2024 00:11, Mike Frysinger wrote:
> On 15 Feb 2022 23:03, Damian Szuberski wrote:
> > A standard `libtool` invocation line generated by automake looks like:
> > ```
> > LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> > $(LIBTOOLFLAGS)
On 15 Feb 2022 23:03, Damian Szuberski wrote:
> A standard `libtool` invocation line generated by automake looks like:
> ```
> LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPF
On 16 Jan 2024 22:43, Roumen Petrov wrote:
> Mike Frysinger wrote:
> > On 13 Jan 2024 22:29, Bogdan wrote:
> >> Mike Frysinger , 2024-01-13 07:19:
> >>> On 15 Mar 2023 17:31, Bogdan wrote:
> >>>> Another patch from my side. This one makes it possibl
On 14 Jan 2024 18:55, Bogdan wrote:
> Mike Frysinger , 2024-01-14 02:06:
> > On 13 Jan 2024 22:29, Bogdan wrote:
> >> Mike Frysinger , 2024-01-13 07:19:
> >>> On 15 Mar 2023 17:31, Bogdan wrote:
> >>>> Another patch from my side. This one makes it
On 13 Jan 2024 15:58, Karl Berry wrote:
> Another alternative: when this came up 30-odd years ago, rms changed the
> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
> that would at least have the benefit of following a recommendation, and
> as a side effect, would also fix jami
On 13 Jan 2024 22:29, Bogdan wrote:
> Mike Frysinger , 2024-01-13 07:19:
> > On 15 Mar 2023 17:31, Bogdan wrote:
> >>Another patch from my side. This one makes it possible for users to
> >> pass additional options to libtool in 'compile' mode. Fixes #54020.
On 21 Mar 2023 23:05, Bogdan wrote:
> Third, and most important (I think) is that we need to note that
> "prog/x.py" is GENERATED, but is NOT marked so. Adding
>
> BUILT_SOURCES = prog/x.py
i don't think this is a correct use of BUILT_SOURCES.
https://www.gnu.org/software/automake/manual
On 15 Mar 2023 17:31, Bogdan wrote:
> Another patch from my side. This one makes it possible for users to
> pass additional options to libtool in 'compile' mode. Fixes #54020.
>
> Added documentation and a test case including the '-no-suppress'
> option. All tests with 'lt' or 'libtool' in t
On 09 Mar 2023 08:47, Sam James wrote:
> xz supports parallel compression which obviously speeds up
> the time taken to run the 'dist-xz' rule, but it also
> speeds up *decompression* too, as the parallel compressor
> creates different output which can be decompressed in parallel.
>
> There's two
On 06 Jan 2024 15:37, Karl Berry wrote:
> Automake and other packages have used letters for pretests for decades,
true ...
> and it's not plausible to change now.
eh ? there is nothing requiring or restricting the current version behavior
other than "it's always been this way". but that doesn'
On 02 Dec 2023 21:55, Paul Eggert wrote:
> -if test -z "$PERL"; then
> +case $PERL in
AS_CASE ?
-mike
signature.asc
Description: PGP signature
On 12 Apr 2023 18:14, Reuben Thomas via Bug reports for Automake wrote:
> On Wed, 12 Apr 2023 at 17:59, Reuben Thomas wrote:
> > On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote:
> >
> >> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
> >> a parallel build (in my case,
On 30 Nov 2023 22:45, Nick Bowler wrote:
> Interestingly the libtool manual also says "If [libtool] can't infer a
> tag, then it defaults to the configuration for the C language", which is
> clearly not the case (it seems what actually happens is that if libtool
> can't infer a tag then it exits
On 02 Dec 2023 15:53, Karl Berry wrote:
> also, can we really not trust the exit status of grep ?
> if echo "$PERL" | grep -q '[\t ]'; then
>
> Exit status yes, but at least historically, grep -q has been considered
> non-portable, in favor of grep ... >/dev/null.
i get that `grep
On 27 May 2023 19:12, Karl Berry wrote:
> I (finally) installed this patch to quit early if the perl path has
> spaces. Thanks.
>
> As for MKDIR_P and INSTALL, I guess it is somewhere in the
> prerequisite/autoconf stuff. I suppose it would be rare that they would
> be found in a path with spaces
On 24 Jan 2023 07:06, Bert Wesarg via Bug reports for Automake wrote:
> On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg wrote:
> > On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake
> > wrote:
> > > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger
On 14 Jan 2023 01:30, Nick Bowler wrote:
> On 2023-01-13, Mike Frysinger wrote:
> > On 13 Jan 2023 16:01, Karl Berry wrote:
> >> I am doubtful about blithely defining .POSIX unconditionally. I feel
> >> sure that will break existing Makefiles. I don't think we sho
On 13 Jan 2023 13:52, Tim Ruffing wrote:
> On Fri, 2023-01-13 at 05:52 +0000, Mike Frysinger wrote:
> > i think the expectation is that, if you're using libtool, then you
> > use libtool.
>
> Well, I *use* libtool. libtool needs some AR. I choose to use
> libtoo
On 13 Jan 2023 16:01, Karl Berry wrote:
> I am doubtful about blithely defining .POSIX unconditionally. I feel
> sure that will break existing Makefiles. I don't think we should do that.
>
> Detecting .POSIX in an existing Makefile.am and moving it to the front
> sounds desirable, since that is cl
On 13 Jan 2023 07:07, Sam James wrote:
> $ /tmp/libaacs/configure YACC=bison LEX=flex
the problem is you're forcing `YACC=bison`. Automake defaults to `bison -y`
which tells bison to operate in POSIX-yacc-compatible mode because Automake's
rules target POSIX. the end result is that you've forced
On 13 Jan 2023 06:29, Sam James wrote:
> > On 13 Jan 2023, at 06:13, Mike Frysinger wrote:
> > On 14 Mar 2022 17:21, Sam James wrote:
> >> It appears that YACC rules don't check for whether the destination
> >> directory exists before executing ylwrap.
> &
On 19 Apr 2022 17:33, Vincent Lefevre wrote:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
> says about the target rules:
>
> .POSIX
> The application shall ensure that this special target is specified
> without prerequisites or commands. If it appears as the fir
On 14 Mar 2022 17:21, Sam James wrote:
> It appears that YACC rules don't check for whether the destination directory
> exists before executing ylwrap.
>
> When trying to package libaacs (https://code.videolan.org/videolan/libaacs)
> with an out-of-source build, I hit an unexpected build failure
On Mon, 17 Dec 2018 20:11:48 +0100, Bert Wesarg wrote:
> looking at lib/am/ltlib.am, the rule for installing libraries looks
> weird for the !LIBTOOL case. Though I have the impression that this
> file should not be used at all, if libtool is not used. Nevertheless,
> the install command in this ca
On Wed, 16 Mar 2022 15:24:37 +0100, Tim Ruffing wrote:
> Assume environment variable AR="lib.exe" and configure.ac has
>
> ```
> AM_PROG_AR
> LT_INIT
> ```
i think the expectation is that, if you're using libtool, then you
use libtool. it can create static convenience libraries too:
https://www.g
i have a project that generates a bunch of arch-specific archives. i also have
an intermediate archive for holding common objects (so only need to build them
once). i noticed that while (ab)using LIBADD & OBJECTS variables, Automake
incorrectly omits propagating OBJECTS variables from LIBADD to D
Fixes automake bug https://bugs.gnu.org/54363.
There is no "aclocal" manual as it's all integrated into the automake
manual, so have all the help2man calls force automake as the manual.
* doc/local.mk: Use --info-page=automake for man pages.
---
doc/local.mk | 2 +-
1 file changed, 1 insertion(+
On 13 Mar 2022 00:45, Esteve Varela Colominas wrote:
> Running "man aclocal" mentions the availability of a full texinfo manual for
> the tool at the bottom. However, running "info aclocal" brings up the same
> man page. I'd like to have this texinfo page shipped alongside the texinfo
> page tha
On 28 Feb 2022 15:58, Karl Berry wrote:
> Fixes automake bug https://bugs.gnu.org/32868.
>
> Looks fine to me.
>
> +./configure -C
> +grep '^AM_DEFAULT_VERBOSITY = 1' Makefile
>
> Good :).
>
> I remain steadfastly opposed to (ever) changing the default to be silent
> rules, as we've
Fixes automake bug https://bugs.gnu.org/32868.
The AM_SILENT_RULES macro defines all the silent-rules related setup.
It's also called by users to change the default verbosity level. This
leads to a quirk where automake calls it, expands the full context,
and then users call it, and it's fully exp
On 22 Feb 2022 12:53, Jeff Squyres (jsquyres) wrote:
> I'm afraid I can't easily tell.
>
> It looks like I added a workaround in
> https://github.com/open-mpi/ompi/commit/40dd4c5b766ff62a681692b1fa6b72a1023fc81f
> on Dec 20, 2014 (the same day that I initially filed this bug report).
>
> Half o
On 25 Feb 2022 16:06, Karl Berry wrote:
> Adding a note to the manual is fine, but what would be (much) more
> likely to actually get noticed by users is a runtime warning. What is
> the actual behavior when the basename and @setfilename don't match?
i don't think it's possible to detect from auto
On 24 Feb 2022 11:23, Thomas Klausner wrote:
> FAIL: t/distcheck-override-infodir
> FAIL: t/instdir-texi
> FAIL: t/silent-texi
> FAIL: t/txinfo-builddir
> FAIL: t/txinfo-clean
> FAIL: t/txinfo-info-in-srcdir
> FAIL: t/txinfo-include
> FAIL: t/txinfo-many-output-formats
> FAIL: t/txinfo-many-output-
Fixes automake bug https://bugs.gnu.org/54063.
The function scanning for @setfilename will fall back to a default
value if the input doesn't have one defined. But we need to handle
the case where the file doesn't even exist before falling back.
* bin/automake.in: Scan /dev/null for @setfilename
On 24 Feb 2022 11:19, Patrice Dumas wrote:
> On Thu, Feb 24, 2022 at 01:52:21AM -0500, Mike Frysinger wrote:
> > On 19 Feb 2022 15:03, Patrice Dumas wrote:
> > > In Texinfo, we have a texinfo manual which is automatically generated
> > > from Pod sections from Texin
Fixes automake bug https://bugs.gnu.org/20713.
If `id` fails, display a specific warning message to the user.
* m4/tar.m4: Check $am_uid & $am_gid if they're unknown.
---
m4/tar.m4 | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/m4/tar.m4 b/m4/tar.m4
index 7
On 19 Feb 2022 15:03, Patrice Dumas wrote:
> In Texinfo, we have a texinfo manual which is automatically generated
> from Pod sections from Texinfo perl modules. When this generated manual
> is removed, automake cannot run anymore. To workaround this issue, we
> have a generation of a fake manual
On 21 Dec 2018 10:46, Thomas Klausner wrote:
> When running the self tests on NetBSD (8.99.27/amd64) with perl
> 5.28.1, I see 26 test failures.
>
> The log is attached.
from the log:
> FAIL: t/instspc
this seems to be due to install-sh being used over normal mkdir -p. but
that should be fine b
On 20 Jan 2019 22:00, Dennis Clarke wrote:
> The usual. Nothing new here. Four failed tests on ye old Solaris 10
> sparc with Oracle Studio 12.6 compiler tools.
>
> test-suite.log attached.
from the log:
> FAIL: t/dist-formats
> + bzip2 -d parallel-compression-1.0.tar.bz2
> bzip2: Caught a SIG
Fixes automake bug https://bugs.gnu.org/32800.
Have the regex match the entire path with word boundaries on both
sides. This should reduce false positives when the full cwd happens
to match parent directories.
* t/silent-custom.sh: Update the header output regex.
---
t/silent-custom.sh | 2 +-
Fixes automake bug https://bugs.gnu.org/7610.
Use of \# is not portable. POSIX does not provide any way of retaining
the # marker in variables. There is wide spread support for \# though
in GNU & BSD Make implementations.
Today, with plain variable assignments, Automake leaves the line alone:
On 23 Feb 2022 01:12, Mike Frysinger wrote:
> my inclination is to introduce two new variables that would be used for
> libtool
> & non-libtool, and only when compiling.
> * xxx_COMPILE: to provide parity with existing xxx_LINK setting -- override
> the compiler on
On 17 Feb 2022 16:33, Karl Berry wrote:
> Hi Damian - thanks for the report.
>
> LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
>
On 22 Feb 2022 16:29, Karl Berry wrote:
> The "test" item, most of the way down in the "Limitations of Shell
> Builtins" node of the Autoconf manual, reports a lot of the things that
> have led to the common forms/workarounds.
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.
On 21 Feb 2022 16:26, Karl Berry wrote:
> should we change "unknown" to $GID & $UID respectively ?
>
> I guess it couldn't hurt, although I doubt it makes any difference in
> practice.
i feel like you just accidentally wrote Automake's motto :p
> if test $am_uid = "unknown"; then
>
> Do
On 21 Feb 2022 12:15, Peter Johansson wrote:
> On 25/1/22 16:24, Mike Frysinger wrote:
> > On 19 Jan 2022 18:32, Peter Johansson wrote:
> >> On 19/1/22 18:10, Mike Frysinger wrote:
> >>> assuming it still fails with Automake 1.16 ...
> >>
> >> I
On Mon, 01 Jun 2015 21:02:32 +, Karl Berry wrote:
> Running a configure script on solaris 5.10 generated with automake-1.15,
> I got these errors about id, which being pre-POSIX, does not support -u:
>
> id: illegal option -- u
> Usage: id [-ap] [user]
> id: illegal option --
Fixes automake bug https://bugs.gnu.org/20300.
The internal method for caching path lookups expects the $filename to
only be a filename. If it's actually a subdir/file itself, then the
cache logic gets confused, and it never matches. This manifests as
AC_REQUIRE_AUX_FILE([subdir/file]) claiming
On Sat, 20 Dec 2014 15:48:49 +, Jeff Squyres (jsquyres) wrote:
> I have found what appears to be a subtle bug in the Autotools, and I *think*
> it may be in Automake. ...but I am not sure; it could also be a bug in our
> m4 code.
it's been ... a while. have you managed to track this down y
On Mon, 02 Mar 2015 13:17:12 +0100, Shahbaz Youssefi wrote:
> I do have a related suggestion nevertheless. You see, no matter how
> many scenarios you think about, there is always some use-case that's
> going to be desired by someone but is unforeseen. Why not just create
> a general rule? My sugge
On 02 Mar 2015 13:17, Shahbaz Youssefi wrote:
> On Mon, Mar 2, 2015 at 12:18 AM, Peter Johansson wrote:
> > On 02/28/2015 02:07 AM, Shahbaz Youssefi wrote:
> >>
> >> To align this with the other -local rules, why not generate it like this?
> >>
> >> check-am: all-am check-local
> >> $(MAKE) $(
Fixes automake bug https://bugs.gnu.org/19961.
* NEWS: Note that check-local may run earlier that before.
* bin/automake.in: Allow check-local to run before check-am instead
of after like check-hook does.
---
NEWS| 5 +
bin/automake.in | 7 +--
2 files changed, 10 insertions(+
Related to automake bug https://bugs.gnu.org/19961.
Add hook support for the check target as requested by Shahbaz Youssefi.
* NEWS: Mention new check-hook.
* bin/automake.in: Run check-hook if defined.
* doc/automake.texi: Document new check-hook.
---
NEWS | 2 ++
bin/automake.in
On 20 Mar 2019 15:21, Дилян Палаузов wrote:
> I expect that the line
>
> a_b_d_e_f_g_SOURCES = a/b/d-e-f.g.c
>
> to be superflous, as this is a “Default _SOURCE”, but `make` fails with
>
> make[1]: *** No rule to make target 'a/b/d-e-f.c', needed by
> 'a/b/d_e_f_g-d-e-f.o'. Stop
>
> g is lost
retitle 20831 `missing` script handling of broken timestamps
tag 20831 = confirmed
thankyou
As pointed out by Eric Blake.
* NEWS: Fix typo.
---
NEWS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 74ad6d612560..c5ccd9387c0a 100644
--- a/NEWS
+++ b/NEWS
@@ -821,7 +821,7 @@ New in 1.13:
- The missing script has thus become useless as a (poor) way t
Fixes automake bug https://bugs.gnu.org/53340.
If the system has xargs, then utilize it to uninstall files to stay
within long command line limits. If the system doesn't have xargs,
fall back to running the remove command one at a time. Since every
reasonable system should have `xargs -n`, and P
On 20 Feb 2022 19:14, Mike Frysinger wrote:
> --- a/m4/silent.m4
> +++ b/m4/silent.m4
> @@ -5,12 +5,12 @@
> # gives unlimited permission to copy and/or distribute it,
> # with or without modifications, as long as this notice is preserved.
>
> -# AM_
On 20 Feb 2022 15:25, Karl Berry wrote:
> Use of \# is not portable.
>
> Is there any known make implementation which does not preserve the #?
>
> foo = blah\#blah
> foo += what
> -> warning: escaping \# comment markers is not portable
> -> foo = blah\#blah what
>
> A
On 20 Feb 2022 16:27, Zack Weinberg wrote:
> > i'm inclined to bring this back as the way to opt-in to silent-rules
> > by default.
>
> And I’m still absolutely opposed to making it even *possible* to have silent
> rules be on by default. In fact I’d like to see —enable-silent-rules removed,
> w
Fixes automake bug https://bugs.gnu.org/32868.
The AM_SILENT_RULES macro defines all the silent-rules related setup.
It's also called by users to change the default verbosity level. This
leads to a quirk where automake calls it, expands the full context,
and then users call it, and it's fully exp
On 28 Sep 2018 20:47, Jacob Kroon wrote:
> If I use AM_SILENT_RULES([yes]) in my configure.ac, when I run the
> configure scripts I see this:
> ...
> checking whether make supports nested variables... yes
> checking whether make supports nested variables... (cached) yes
> ...
>
> If I remove AM_SI
On Fri, 27 Mar 2015 17:45:30 +0100, Pavel Raiskup wrote:
> On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote:
> > I just stumbled across an issue where a project fails to compile using
> > automake and silent-rules with $V being set to sth. else other than '1'
> > or '0'.
> >
> > This is bec
On Mon, 28 Mar 2011 09:36:45 +0200, A.T.Hofkamp wrote:
> As far as I know, "make install prefix=/path/to/writable/dir" should only
> change the place where
> files are copied to, instead of injecting that new prefix into the source
> code. However, for Python
> source files that are generated/m
Fixes automake bug https://bugs.gnu.org/20031.
The C++ standard does not require symbols be placed into the global
namespace, just in the std namespace. The GNU implementation will
place symbols in both. For our specific code, we don't care either.
Unfortunately, it looks like generated flex co
On 17 Dec 2014 17:13, Stefano Lattarini wrote:
> AC_PROG_CC called before AC_CONFIG_AUX_DIR can silently force wrong
> $ac_aux_dir definition.
looks like this was merged to fix this bug but forgot to close the report
-mike
On Fri, 26 Jul 2013 11:32:18 -0400, Diab Jerius wrote:
> The fort5 test fails on Mac OS X 10.6.8.
the failing part of the log:
/bin/sh ./libtool --tag=FC --mode=link gfortran -g -O2 -o libhello.la
-rpath /usr/local/lib foo.lo bar.lo libgoodbye.la
libtool: link: gfortran -dynamiclib -Wl,-u
Fixes automake bug https://bugs.gnu.org/7610.
Use of \# is not portable. POSIX does not provide any way of retaining
the # marker in variables. There is wide spread support for \# though
in GNU & BSD Make implementations.
Today, with plain variable assignments, Automake leaves the line alone:
On 04 Feb 2022 17:12, Valio Valtokari wrote:
> I have a project that supports multiple platforms (windows and linux as of
> right now). To implement testing functionality I use a library that I
> haven't configured for windows in my project yet. As such, my configure.ac
> has these lines:
>
> AC_C
Fixes automake bug https://bugs.gnu.org/10828.
Delete the configure check that would abort if `rm -f` does not work,
and delete the plans to make this a hard requirement in the future.
Instead, test to see if `rm -f` fails w/out arguments. If it does,
define am__rm_f such that it always passes a
On 14 Feb 2022 01:14, Daniel Richard G. wrote:
> On Mon, 2022 Feb 7 23:03-05:00, Mike Frysinger wrote:
> > can you provide an example that reproduces the issue ? or link to the
> > package you're working on (assuming it's OSS) ? i checked my own
> > projects and
closing this issue out. the original report has been settled, we've merged
support for ignoring -nologo, but the -xilib suggestion looks like it needs
more work. feel free to post a patch to automake-patc...@gnu.org if you have
something you think we can merge.
-mike
signature.asc
Description:
Fixes automake bug https://bugs.gnu.org/21547.
If users have interactive site file logic, the lispdir probing can
hang, as can the compilation of elisp files. Use --no-site-file to
disable loading any of that possible user logic.
* NEWS: Note emacs --no-site-file change.
* doc/automake.texi: Run
From: Mathieu Lirzin
Fixes automake bug https://bugs.gnu.org/30172.
Since AM_MAKEINFOHTMLFLAGS overrides AM_MAKEINFOFLAGS only for html
targets, make sure we restore the hacked up makefile before testing
the non-html formats. This normally doesn't cause a problem for most
people, but if their t
On 19 Jan 2018 16:30, Mathieu Lirzin wrote:
> The test suite fails for “t/txinfo-many-output-formats.sh” and
> “t/txinfo-many-output-formats-vpath.sh”.
>
> $ make check \
> TESTS="t/txinfo-many-output-formats.sh
> t/txinfo-many-output-formats-vpath.sh"
>
> TEXINPUTS=".:$TEXINPUTS" \
> MAK
On Fri, 09 Sep 2016 18:18:07 -0700, Michael Miller wrote:
> I recently had a problem building automake via Homebrew on OS X. Turns out
> the problem was that the path to Xcode contained a space: /Applications/Xcode
> 7.app \u2014 Removing the space caused the build to work correctly.
>
> To Repro
We already invoke $AR with -NOLOGO all the time, so we can ignore the
option entirely if the user specifies it.
* lib/ar-lib: Ignore -NOLOGO.
---
lib/ar-lib | 4
1 file changed, 4 insertions(+)
diff --git a/lib/ar-lib b/lib/ar-lib
index 9dc8ef6df054..54c6bdbf7f1b 100755
--- a/lib/ar-lib
+++
On 13 Mar 2019 20:23, Hans-Bernhard Bröker wrote:
> Am 13.03.2019 um 16:44 schrieb Allwright, James:
> > I believe I have found a bug in automake relating to the parsing of
> > filepaths and/or directories.
>
> I believe you have used automake incorrectly.
>
> > In proj3/ Makefile.am I have
> >
On Tue, 13 Jan 2015 01:01:44 -0500, Daniel Richard G. wrote:
> I am building a source package, prepared with Automake 1.15, on HP-UX.
> While running the configure script, I get
>
> [...]
> config.status: creating include/Makefile
> config.status: creating scripts/Makefile
> config.
On 06 Feb 2022 15:47, Karl Berry wrote:
> Fixes automake bug https://bugs.gnu.org/38043.
>
> All these changes look good to me (just casting my eyes over them ...),
> and hopefully will result in something more future-maintainable. Thanks!
before i push, question about $scriptversion. is the
turns out this doesn't repro in official automake versions because it requires a
Gentoo-specific patch -- the one sent for #38043 to fix Python 3.5+ compilation.
the issue is that lib/am/python.am chops up the list of files before the globs
are expanded instead of after.
## This is somewhat tricky
ugh, cc-ed bug-automake by accident and got a dupe report. closing this.
https://bugs.gnu.org/18564
astle dalg...@ix.netcom.com
Mike Frysinger vap...@gentoo.org
diff --git a/lib/py-compile b/lib/py-compile
index f72d4945da96..d34bb2dd2364 100755
--- a/lib/py-compile
+++ b/lib/py-compile
@@ -131,6 +131,13 @@ case $python_major in
;;
esac
+python_minor=`$PYTH
The compilation steps print the filename as it runs, but forgets to add
a space after it, so they all get squashed together:
$ ./py-compile 1.py 2.py 3.py
Byte-compiling python modules...
1.py2.py.3.py
* lib/py-compile: Add missing write.
---
lib/py-compile | 4 ++--
1 file changed, 2 insertions(
Python 2.0 was released in 2000. There's really no way for us to check
those old versions, so let's just drop them. No one will miss them.
* lib/py-compile: Abort if major version 0 or 1 is found.
* t/py-compile-env.sh: Rework slightly to handle new version probing.
---
lib/py-compile | 35
Clarify to users what versions of Python are supported and until when.
This will make it easier for us to decide what versions to support.
* doc/automake.texi: Add Supported Python versions section.
---
doc/automake.texi | 53 +++
1 file changed, 53 ins
The list of files is put into a string and then split on whitespace.
Fix the way the list of files are passed to the compile script.
* lib/py-compile: Pass files as arguments, not as a string.
* t/py-compile-files.sh: New test.
---
lib/py-compile| 14 +-
t/py-compile-files.sh
Include the full summary of options in the output.
* lib/py-compile: Update usage output.
* t/py-compile-usage.sh: Update test to match new output.
---
lib/py-compile| 8 +++-
t/py-compile-usage.sh | 4 ++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/lib/py-compile
see the attached example configure.ac & Makefile.am. it fails:
$ autoreconf -vfi
...
Makefile.am: error: object 'source.$(OBJEXT)' created both with libtool and
without
if the Makefile.am line is enabled though:
lib_a_CFLAGS = $(AM_CFLAGS)
it works. seems like we should be able to handle this
i believe this will be fixed in the next release with the patches i
just merged. please feel free to reopen if that doesn't work out.
-mike
signature.asc
Description: PGP signature
Fixes automake bug https://bugs.gnu.org/23599.
When generating info/html pages, automake adds -I flags to source
dirs that contain the texi files, but it doesn't do this for dvi or
pdf formats. Instead, automake has been relying on texi2dvi to use
makeinfo for expanding macros, and it hasn't done
To provide a bit more flexibility when invoking TEXI2DVI & TEXI2PDF,
and provide a bit of symmetry with .info & .html generation, provide
a AM_TEXI2FLAGS setting that is passed to all TEXI2xxx invocations.
* doc/automake.texi: Mention new AM_TEXI2FLAGS setting.
* lib/am/texibuild.am: Pass $(AM_TEX
On 26 Jan 2022 19:50, Karl Berry wrote:
> I don't really understand why this patch is in two parts, with seemingly
> the same change, but whatever, doesn't matter.
they're logically independent things. one fixes a bug by adding -I paths,
the other is a nice-to-have new feature.
> * doc/autom
On 26 Jan 2022 19:50, Karl Berry wrote:
> +## if it is in srcdir (-I $(srcdir) is set in %MAKEINFOFLAGS%), and in
> case
> +## texi2dvi automatically fallsback to using makeinfo for expanding (-E).
> +## If texi2dvi doesn't fallback, we also pass %MAKEINFOFLAGS% directly
> below.
>
>
On 26 Jan 2022 06:37, Mike Frysinger wrote:
> Fixes automake bug https://bugs.gnu.org/53530.
>
> Based on the cadence of Automake releases, add the current Python
> release (3.10), the current Python development (3.11), and then 4
> more versions on top of that. It doesn't
On 26 Jan 2022 10:09, Zack Weinberg wrote:
> On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote:
> > Fixes automake bug https://bugs.gnu.org/53530.
> >
> > Based on the cadence of Automake releases, add the current Python
> > release (3.10), the current Python dev
Fixes automake bug https://bugs.gnu.org/53530.
Based on the cadence of Automake releases, add the current Python
release (3.10), the current Python development (3.11), and then 4
more versions on top of that. It doesn't hurt to check for a few
extra versions here since this is the fallback logic
On 19 Jan 2022 18:32, Peter Johansson wrote:
> On 19/1/22 18:10, Mike Frysinger wrote:
> > retitle 17614 parallel compilation fails: mv:
> > yat/statistics/.deps/Percentiler.Tpo and
> > yat/statistics/.deps/Percentiler.Tpo are the same file
> > tag 17614 = moreinfo
should be resolved for the next release, thanks
1 - 100 of 159 matches
Mail list logo
