I received an answer from the German Sovereign Tech Fund regarding
our application for their bug resilience program. Automake is on the
waiting list for next year.
Thanks Christoph!
Hi Detlef - I think Christoph has already submitted the application to
the fund, in somewhat different form than the one you commented
on. There are some subsequent msgs between he and I on the list. (In
short, I basically agree[d] with all your comments. We probably didn't
get everything right fo
I added your paragraph to the section "Describe why your project needs
those services?"
Sounds good.
Can I submit the application?
Yes. Time to give it a try. Thanks for the initiative. --best, karl.
1) It looks to me like GCC uses autoconf but not automake. Maybe change the
answer to:
> Where is your open source technology project being
> used (describe all user bases)?
GNU Automake is used by a very large number of GNU and non-GNU packages.
Here are just a couple of examples: GNU coreutils
A physical entity should always be displayed with its unit.
Agreed in principle, but sorry, I'm not ready to install this one.
Adding a unit to the value and then removing it everywhere the value is
used seems error-prone to me. How about just displaying it with the
unit (somehow)? Or having
checking whether sleep supports fractional seconds... true
is inconsistent with the rest of the GNU Build System. Namely, in
configure output, results are "yes"/"no", not "true"/"false".
The attached patch makes automake consistent with the rest.
Thanks Bruno. I applied, plus "qu
ts.gnu.org/archive/html/automake/2024-06/msg00085.html
+# (The actual purpose of the "$()" is unclear.)
+
+. test-init.sh
+
+cat > Makefile.am << 'END'
+x:
+ $()
+END
+
+$ACLOCAL
+$AUTOMAKE
+
+:
Running command: git commit \-q \-F \.\/vc\-dwim\-log\-wBh6_U \-\-auth
Hi Christoph and all - back on the Sovereign Tech Fund
application. Here's my first cut at tweaking the wording.
Thanks for doing all this. -k
Draft of applications (questions are with > at the left of the line):
> I acknowledge:
>
> All code and documentation to be supported mu
Hi Dave,
in case it affects a decision to release 1.17
Indeed. Thank you very much for the report (and the followup). The first
question that comes to mind: are you using the same version of libtool
in the various cases? --thanks again, karl.
Subject: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.
FWIW, it sounds good to me. To my mind, logging is one of the most
important features of autoconf, so I'm all for macros to support it
further. --thanks, karl.
I ran a mass rebuild on Fedora for packages that depend on automake with
this version.
Thank you!!
Out of 1330 packages built, I found the following failures.
Could be a lot worse!
NetworkManager
x2gokdrive
xorg-x11-server
Use of uninitialized value $var in string e
Why two blank lines, not just one as for the other scripts?
Slip of the editor. Will fix. Thanks for the sharp eyes. -k
have to say --enable-maintainer-mode
Personally I agree with you, in theory, but I think it is too big of a
change to make. As I understand it. GNU package authors have their
source repos and have never had to say --enable-maintainer-mode before
to get their Makefiles etc. rebuilt. I don't thi
Let's look at the history.
Thanks very much for all that research and explanations, Bruno.
Likewise, Jacob.
https://lists.gnu.org/archive/html/bug-automake/2010-10/msg0.html
Aha, the explanation for some of the $sleep commands scattered
throughout the Automake tests! I had no idea. I
Nick>
AC_CONFIG_COMMANDS_POST([cat >conftest.mk <<'EOF'
configure: config.status
false
EOF
while ${MAKE-make} -f conftest.mk >/dev/null 2>&1
do
touch config.status
done])
One missing element is that there is no limit, which would be a
Christoph - I had one more thought about the tech fund: Automake is
copyright FSF. So Neighorhoodie is going to need to sign a disclaimer or
(preferably) assignment for any patches to be usable. Is there precedent
in the fund for doing that? --thanks, karl.
make(1) in AM_SANITY_CHECK seems to be a logic error, since the user
may want to build with a different $MAKE,
You're right. Crap. It never ends.
In practice it probably doesn't matter, though. Although in theory one
can imagine that "make" succeeds while $MAKE fails, resulting in a fals
Find here attached a revised proposed patch.
Ok on the reorg, but sorry, I remain confused. This whole thing started
with Mike Vapier's change in Feb 2022 (commit 720a11531):
https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html
As I read it now, his goal was to speed up ot
Hi Christoph,
All Automake release announcements since 2.13 warn about
future Automake 2.0 incompatibilities.
I moved that noisy warning from the top of NEWS into a separate NEWS-2.0
file a couple of releases ago.
At the beginning there is a meeting between you (maybe more people,
Hi Christoph,
I advice everybody so seek alternatives.
I'm sorry to hear it. My own personal experience (with my sysadmin hat
on) is that all alternatives have been inferior. Which is, ultimately,
why I choose to spend my time here.
I would love to see any minor improvement, as the docum
Jacob,
[*sigh*]
You said it. About this whole thing. I rather wish this bright idea had
never come to pass. It has delayed the release by months. Oh well.
Still, could we use make(1) for *all* of the testing and not use `ls -t`
I guess it is technically possible, but I somehow feel dou
Sorry, but I don't really understand your patch. With it, it would seem
that _AM_FILESYSTEM_TIMESTAMP_RESOLUTION is only called if the build
environment is not "sane", i.e., a created file is not newer than
configure. Is that right? (That embedded shell construct is hard to grok.)
is in _AM_FI
Does BSD ls(1) support "--time=ctime --time-style=full-iso"?
BSD ls does not support any --longopts. Looking at the man page,
I don't see "millisecond" or "subsecond" etc. mentioned, though I could
easily be missing it. E.g.,
https://man.freebsd.org/cgi/man.cgi?ls
Even if there is such an
It should save 6 seconds. Because it goes like this:
- Test whether 0.01 sec works.
- Test whether 0.1 sec works.
- If not, set the variable to 2, because that's the worst case and it
*must* work.
At which places will then a 'sleep 2' be done where (if not VFAT) a
> Any other ideas?
A horrible one:
:)
split the test so it can be performed in parallel with
others -- upper half starts the sleep in the background, lower half
waits for it to complete.
No thanks. I can't even begin to imagine the portability and edge case
problems that w
Maybe this is a silly question, but, is there a reason why this test
needs to be performed in every single package that uses Automake?
I was under the impression that the purpose of this test was merely
to speed up running Automake's own test suite.
There are other packages that h
Hi Christoph,
https://www.sovereigntechfund.de/programs/bug-resilience
Thanks for bringing this up.
> Our partner 'Neighbourhoodie Software' provides a variety
> of types of contributions to participating projects to
> address known issues,
If that means providing patches fo
bh> Seen e.g. on NetBSD 10.0.
Which doesn't support subsecond mtimes?
jb> Maybe the best answer is to test for subsecond timestamp
granularity first, and then only do the slow test to distinguish
between 1-second and 2-second granularity if the subsecond
granularity test gives
Date: Sat, 08 Jun 2024 00:27:39 +0200
From: Bruno Haible
To:
Subject: 1.16.90 regression: configure now takes 7 seconds to start
[I'm writing to automake@gnu.org because bug-autom...@gnu.org
appears to be equivalent to /dev/null: [...]
It seems this has been fixed, what
Hi Christoph,
end of 2023 you shared the news that automake release 1.17 could happen
Indeed. Unfortunately since then I have had to attend to other priority
projects, and there's no one else driving automake. I hope to be able to
spend some time on automake again soon to bring the release t
Automake does have a critical bug in that for a target which only
optionally has C++ sources, that target is always linked using C++.
So it should only use C++ if the "option" is selected?
Can you provide a test tree?
Without this issue, the trick of including an empty optional C++
convince Automake to force libtool to link using the C++ compiler
When there are no C++ sources? Why? Just trying to understand ...
I'm sorry Bob, but I just don't know. Maybe the just-released
libtool-2.5.0 alpha offers some new help?
If there is some bug in or feature for Automake that wo
I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes.
I'm not sure GNU explicitly recommends anything. Although the tarball
examples in standards.texi and maintain.texi all use gz, I don't think
even gz is explicitly
`distcheck` target's prominence to recommend it in the "Standard
Targets for All Users" section of the GCS?
Replying as an Automake developer, I have nothing against it in
principle, but it's clearly up to the GNU coding standards
maintainers. As far as I know, that's still rms (for anyth
Hi Bob,
It is my opinion that if a library or program
is linked with C++ libraries (and especially if it is a static build!)
that it should be linked using the C++ linker. Likewise, if a library
or program does not depend on, or contain any C++ code, it should be
linked wi
Does anyone know what this line in automake-generated test-suite.log
files is used by or intended for?
. contents:: :depth: 2
It appears to be machine-parsable, but I can't find any reference to it
in the code or the doc. There doesn't seem to be anything that outputs
:depth: 3 (or anything else)
The GNU Automake 1.16j development snapshot is now available. Download here:
https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.xz
https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.gz
We intend for automake 1.17 to be released soon, essentially with only
bug fixes for whatever is found
While reading the announcement for 1.16i, I found a typo in the
NEWS file "New in 1.17" section.
I have also accidentally found a typo in the "New in 1.15"
section,
Thanks x 2, Hans. Applied.
which might need a line rewrap after the fix.
Nah, it's ok.
I have not system
Hi Zack,
*automake* can exit with code 63 under
some circumstances, but it really looks like aclocal never will.
Agreed. I searched for "63" in automake distributions back to 1.11.3, as
well as the current sources, and no trace of any 63's in aclocal, only
in automake. Thus I suspect that
We are pleased to announce the GNU Automake 1.16i development snapshot.
We intend for automake 1.17 to be released soon, essentially with only
bug fixes for whatever is found in this pretest. So please do test if at
all possible.
It's our primary goal to preserve compatibility. If this release of
Features: subsecond-timestamps
Sounds good to me, FWIW. Thanks to all. -k
I thought we were talking about automake's testsuite probing the behavior
of *autom4te*
Yes, exactly. Sorry for the confusion.
$ ./tests/autom4te --version
autom4te (GNU Autoconf) 2.72d.6-49ab3-dirty (subsecond timestamps supported)
Looks good to me. Thanks.
a third party C
upthread somewhere Karl (iirc) threw out a bikeshed idea like
--has=.
Pretty sure it wasn't me :).
> There would not need to be much parsing, just "automake --version | grep
> HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> easc" to avoid running grep if you want.
I specifically want to hear what Karl thinks.
I lean towards Jacob's view that automake --
The best way to check if high-resolution
timestamps are available to autom4te is to have perl load
Autom4te::FileUtils and check if that also loaded Time::HiRes.
The problem with that turned out to be that Time::HiRes got loaded from
other system modules, resulting in the test thinki
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 i
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 -
The regex pattern in function scan_variable_expansions() fails to
report a portability warning when a dollar-escaped dollar sign
precedes the variable:
foo_SOURCES = a.c $$$(patsubst a.c,a,b)
Thanks much, Jan. It all worked for me. Pushed. --karl
The regex pattern in function scan_variable_expansions() fails to
report a portability warning when a dollar-escaped dollar sign
precedes the variable:
foo_SOURCES = a.c $$$(patsubst a.c,a,b)
Thanks Jan. Any chance you could add a check to one of the tests, I
guess dollarv
This will work iff AM_PROG_LEX uses AC_REQUIRE to invoke
AC_PROG_LEX.
Evidently so. From automake's m4/lex.m4:
AC_DEFUN([AM_PROG_LEX],
[AC_PREREQ([2.50])dnl
AC_REQUIRE([AM_MISSING_HAS_RUN])dnl
AC_REQUIRE([AC_PROG_LEX])dnl
if test "$LEX" = :; then
LEX=${am_missing_run}flex
fi])
Hi Jan,
Current automake likely won't have anything in store already,
Not that I know of.
a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c)
I've often wanted this myself. I'd certainly welcome a patch for it.
Please work from automake trunk. None of the various branches are kept
Hi Zack,
Date: Fri, 07 Oct 2022 11:35:41 -0400
From: Zack Weinberg
[...]
the filesystem timestamp resolution was incorrectly detected:
Your analysis sounds plausible to me, but it's not obvious to me how
best to fix it. ls --full-time or stat may not be available.
Maybe just do
Hi Bogdan,
Then, I analysed the files and added the trick from t/backcompat2.sh
(if possible) and/or removed the extra calls to $ACLOCAL (if possible).
Thanks much for looking into this.
Short version: after a few hours of testing and modifications, I
*may* have saved up to 1 mi
Are you sure about that?
Yes. Well, as sure as I can be. I don't see any $(...) constructs in
Automake's *.m4 now, and this is certainly deliberate. We discussed
shell portability many times over the decades of Automake development.
I can't quickly find where it's documented, if anywhere, but
Hi Jacob,
The guess was the two most probable locations: /usr/share/autoconf and
/usr/local/share/autoconf.
Wouldn't have worked on my own system :).
Challenge accepted.
Thanks!
if $PERL -I${autom4te_perllibdir:-$(sed -n \
'/autom4te_perllibdir/{s/^.*|| //
jb> The test also guesses the location of autoconf's Perl libraries;
I'm skeptical that any "guessing" of library locations would be reliable
enough.
jb> a more thorough test would locate the autom4te script and grep it
for the perllibdir that was substituted when autoconf was
co
Is there a way to time individual tests
I don't know. Maybe one of the more experienced automakers here can
advise.
Makes me wonder about having the test infrastructure start each test
by running date to get the start time into the log file. Does anyone see
a problem with doing that?
The m
# A trick to make the test run muuuch faster, by avoiding repeated
# runs of aclocal (one order of magnitude improvement in speed!).
echo 'AC_INIT(x,0) AM_INIT_AUTOMAKE' > configure.ac
Hadn't noticed this before. Maybe you could see what tests are currently
taking the longest to run, a
I modified my autom4te using the attached patch,
Thank you very very much for finding this, Bogdan.
I'm glad that Paul has already installed it in Autoconf.
I can't easily confirm it for myself right now, but I'm hopeful.
(Maybe Frederic or others can try with the development autoconf.)
W
Note that 'config.h' is older (4 seconds) than './configure', which
shouldn't be the case as it should get updated with new values.
Indeed. That is the same sort of thing as I was observing with nodef.
But what (at any level) could be causing that to happen?
Files just aren't getting upda
Hi Frédéric,
While building the trunk directly led to check failures,
Confirmation is good.
rebuilding the RPM in a mock environment didn't.
Puzzling.
I'll likely spend more time next week to perform more testing. It
may simply be an environment problem:
I guess it's possibl
FAIL: t/remake-aclocal-version-mismatch.sh
Thanks for trying it, Nick.
I'm glad it's not just me.
And I sure wonder wtf is going on :(. -k
Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky Linux,
original RHEL, or even (sort of) CentOS 8? It would be nice if someone
could run a make check there (from automake dev).
git clone -q git://git.savannah.gnu.org/automake.git
cd automake
./bootstrap
./configure && m
Hi Arsen - sorry for the delayed reply. Replying as one of the automake
developers, though I know nothing ...
src/tangle-main.o \
`test -f 'src/main.cpp' || echo '$(srcdir)/'`src/main.cpp
... which relies on a shell construct, making it hard to 'deduce' from
the point of a pure
Can I actually rely on Automake making a verbatim
copy of the include line from Makefile.am to Makefile.im?
As far as I can make out, your logic is exactly correct. Looking at
the bin/automake script, I see:
my $PATH_PATTERN = '(\w|[+/.-])+';
# This will pass through anything not of the p
Hi Jan,
But when you set `tar_pax` in AM_INIT_AUTOMAKE, this comes out:
I surmise that's left over from when the pax support was added.
I don't see any reason not to use $(TAR) there now.
It presumably shouldn't be too hard to fix. If you can devise a patch
(and ideally test case), that woul
Hi Hans - first, congratulations on getting this to work at all.
I don't recall anyone else undertaking this. I'm afraid I don't have any
particular insights, but just so you know someone read your mail:
Question: Is it OK for me to hook into ./$(DEPDIR)/ at all?
I could use
automake -af --libdir=$HOME/aux
it breaks automake (it can't find other files, e.g. am/header-vars.am).
So, my question: Is there any way to provide 3-rd party aux files?
It seems not :(.
If you, or anyone, can draft a patch, that would be great. As can be
seen by how long it took me
I actually wonder if your sudden "parallelism" failure could be somehow
linked to an update of bash, similar to mine ?
Good idea, but my bash hasn't changed ... I don't doubt there would be
plenty more failures with the new SHLVL change (any such change seems
like a terrible idea, but oh w
No errors on RHEL7+autoconf2.71
Puzzling. Can you easily try RHEL8 or one of its derivatives?
It surprises me that that is the culprit, but it seems possible.
I'm using autoconf-2.71, make-4.3, etc., compiled from source, but am
using the OS-provided coreutils. I think I'll try compiling that
What version of GNU make are you using?
I've been using make 4.3 since its release in 2020. No changes, no
prereleases. I'm afraid the problem, whatever it is, is not that simple :(.
What troubles me most is that there's no obvious way to debug any test
failure involving parallelism, since t
With Zack's latest Python fixes, I was hoping to move towards an
Automake release, but I find myself stymied by apparently random and
unreproducible test failures. I haven't exhausted every conceivable
avenue yet, but I thought I would write in hopes that others (Zack, past
Automake developers, any
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 yo
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 Al
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 ru
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.
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
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
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 i
- @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
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 i
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 clearl
> 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 s
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 t
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 old
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 yo
* 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 thinkin
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
thes
* 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
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 hu
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://ww
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
E
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 a
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
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
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/s
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 kn
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.
Th
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 fr
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
1 - 100 of 179 matches
Mail list logo
