Am 04.10.2021 um 02:40 schrieb Karl Berry:
automake-1.16: error: unrequested trace '$n'
Thanks for the report, but it does not happen for me on CentOS 7, using
automake-1.16.4.
Neither does it for me, actually using Cygwin (current, on Win10
current). And FWIW, the automake version
Am 01.07.2021 um 20:59 schrieb Kasper k:
Then if some intermittent bad situation happens in
unattended/disposable CI environment, as an example, then we won't be
needing to opt into any kind of workaround, it'd be just there right in
the "regular" make-check logs; without introducing crazy
Am 29.11.2020 um 03:46 schrieb Karl Berry:
Looking at 20699, as usual, I'm confused. Sorry. It seems like Automake
is just following instructions. The docs/Makefile.am declares a
dependency on ../src/main.c, so it removes ../src/*.o. How could it
guess otherwise?
Guessing shouldn't be
Am 24.11.2020 um 21:09 schrieb Fabrizio Bertocci:
Karl,
It took me a while to remember what this issue was about... but I
managed to get to my old reproducer.
Ok, let me do one step back. The root problem is how do I ensure that
paths passed through ./configure command line are valid when
Am 24.10.2020 um 17:53 schrieb Karl Berry:
The obvious canonical examples would have to be lex and yacc. They
generate .c and .h files into the blddir, and automake has built-in
mechanisms to include the generated sources into the tarball.
No argument there, but vala is so much
Am 24.10.2020 um 01:14 schrieb Reuben Thomas via Bug reports for Automake:
Unlike include files, you can't simply tell cc to
look in two places for the file it is to compile, so some other solution
is needed.
Actually the traditional VPATH mechanism does not distinguish types of
files at
Am 13.03.2019 um 16:44 schrieb Allwright, James:
> Hi,
>
> 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
>
> SUBDIRS= ../proj3_src
According to what it says on
[Accidentally sent this to Bruno only, before...]
Am 07.12.2018 um 23:39 schrieb Bruno Haible:
> Why is this important? Because without it, maintainers which ONLY use VPATH
> builds on their development machine:
>$ mkdir build-42
>$ cd build-42
>$ ../configure CFLAGS="-O0 -ggdb"
>
Am 27.10.2018 um 12:48 schrieb Stuart Caie:
> I understand that there is a boundary between these two packages, and
> this is not directly automake's problem, even though the main mechanism
> for copying missing files is in automake.
Not for this file it isn't, because as far as automake is
Am 26.10.2018 um 17:06 schrieb Stuart Caie:
> Hello,
>
> the automake macro AM_ICONV requires the auxiliary program config.rpath,
> however automake --add-missing will not install it.
That's because it's not automake's file. Automake has no way of knowing
where to get that file from, nor a
Am 11.05.2018 um 17:40 schrieb Charles Gonnaud:
Hello all,
I encountered some difficulties today when trying to compile automake
1.16.1 from the sources : automake wouldn't compile if the parent
directory was named automake.
[...]
cp -r automake-1.16.1 automake
Ah, but you're not just
Am 05.06.2017 um 00:24 schrieb Mathieu Lirzin:
I suspect this issue has already been fixed in the Git repository, see:
https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=13f00eb4493c217269b76614759e452d8302955e
Indeed, Paul Eggert applied a fix in March 2016.
This will be
Am 08.03.2017 um 20:52 schrieb Peter Selinger:
The tests require this information, for
example when they are shell scripts starting up executable programs
to be tested.
Not really. On the platforms where EXEEXT is non-empty, scripts do
_not_ need to know about it to start executables, i.e.
Am 07.01.2017 um 16:16 schrieb Benno Schulenberg:
On Fri, Jan 6, 2017, at 00:37, Hans-Bernhard Bröker wrote:
and only tries to install nano.info and nano.html if /either/
they already exist or makeinfo is available.
Again, all you have to do is distribute the files, and they'll be
used
Am 04.01.2017 um 21:35 schrieb Benno Schulenberg:
Hi,
What I would like to achieve is that the doc/Makefile that is
the result of ./configure contains rules that only try to build
nano.info and nano.html from nano.texi /if/ makeinfo is available,
That's what the 'missing' mechanism does
Am 14.06.2016 um 09:48 schrieb Ludovic Courtès:
-test ! -s stderr
+
+# Gzip 1.8+ emits warnings like "gzip: warning: GZIP environment
+# variable is deprecated"; filter them out.
+test `grep -v '^gzip: warning' stderr | wc -l` -eq 0
Hmmm... wouldn't it make much more sense to just eliminate
Am 23.06.2015 um 00:05 schrieb Peter Rosin:
On 2015-06-21 23:14, Hans-Bernhard Bröker wrote:
It's actually even a little worse:
Any dependency on sources in another directory causes a simple make clean in
one directory to erase _all_ object files on that other one, i.e. if docs/Makefile.am
It's actually even a little worse:
Any dependency on sources in another directory causes a simple make
clean in one directory to erase _all_ object files on that other one,
i.e. if docs/Makefile.am has
noinst_PROGRAMS = a
a_SOURCES = sub/a.c ../src/main.c
a_CPPFLAGS = -DFOO=BAR
Hello everyone,
I'm just about to turn on option subdir-objects in project gnuplot, but
ran in to a snag. Make distcheck now fails in the distclean phase
because distclean in one subdirectory removes dependency files that
make, in another one, still needs.
The trigger was this in
19 matches
Mail list logo
