Sweet.
The "missing" problem is gone, and I'm now testing the build on about 8
architectures.
This is with the latest CVS automake and autoconf.
Harlan
I'm using the CVS automake with a CVSROOT of:
:pserver:[EMAIL PROTECTED]:/cvs/automake
I'm also using CVS autoconf.
I haven't been able to use a "published" set of the auto* tools for
quite a while for this project.
Harlan
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> I'll update automake again. Strange - I've tried to keep
Harlan> automake reasonably up-to-date.
Are you using the cvs repository at GNU? If so, then that's the wrong
one.
Harlan> Would you prefer I used the wrapped tarball or
Pavel> The next thing I tried was adding "--Werror" to the automake
Pavel> flags in tests/defs. Just four tests now fail unexpectedly (due
Pavel> to warnings that are now errors):
I think adding this is fine for now.
I'm checking in the tests/defs change as well as fixes for the two
bugs. Thank
Ah! My configure still has:
if eval "$MISSING --run :"; then
I'll update automake again. Strange - I've tried to keep automake
reasonably up-to-date.
Would you prefer I used the wrapped tarball or the CVS version?
Harlan
--
> > "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
>
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> I thought we fixed this (twice), but I'm still seeing it:
I don't see the bug I know of in the sources.
We use this code to test:
if eval "$MISSING --run true"; then
Does this appear in your configure script?
Maybe there is
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> It was funny to see 502 in makefiles and wonder what it might be :-)
Believe it or not, this has happened so many times that whenever I see
strange numbers in a Makefile I know it is a quoting bug in automake.
Tom
I thought we fixed this (twice), but I'm still seeing it:
configure: loading cache /dev/null
checking build system type... mips-dec-ultrix4.4
checking host system type... mips-dec-ultrix4.4
checking target system type... mips-dec-ultrix4.4
checking for a BSD compatible install... /usr/bin/install
Hello, Gary!
Thank you very much for this release! The stable release should have been
released soon after 1.4 but it wasn't done. I really appreciate that you
came and did it.
One little problem. If I put "AUTOMAKE_OPTIONS = 1.4-p1" to the
Makefile.am and run CVS Automake I'm getting
Makefile.
We interrupt your regularly scheduled posts with an important news flash:
I am proud to present patch release 1 from the automake-1.4 maintenance
branch. The main purpose of this release is to have a stable automake which
is compatible with the latest stable libtool. It is available now from:
Hello!
The CVS Libtool doesn't compile with CVS Automake. This is the first (and
probably the easiest) problem I faced. I'm applying the patch.
It was funny to see 502 in makefiles and wonder what it might be :-)
ChangeLog:
* automake.in (define_compiler_variable): Escape $(LIBTOOL) in
Hi, Tom!
> Oops, I broke it. Akim checked in the fix.
Now it works. I can use "--Werror --add-missing". Thank you for taking
care of the problem!
The next thing I tried was adding "--Werror" to the automake flags in
tests/defs. Just four tests now fail unexpectedly (due to warnings that
are no
> "Stephan" == Stephan Beal <[EMAIL PROTECTED]> writes:
Stephan> I now sometimes wonder if automake's output (or even required
Stephan> user inputs, like all source and header filenames) couldn't
Stephan> be cut drastically by simply taking advantage of more of
Stephan> make's features
Unfor
> "Felix" == Felix Natter <[EMAIL PROTECTED]> writes:
>> AM_INIT_AUTOMAKE should be doing that already.
>> Why does it detect gtar when you don't have it?
Felix> no, there is a line "TAR = gtar" in Makefile.in, so this is
Felix> probably decided by automake.
What version are you using again
Without this, my machine dies :)
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* automake.in (&am_line_warning): Invoke `am_line_error', not itself.
Index: automake.in
--- automake.in Wed, 09 May 2001 20:11:54 +0200 akim (am/f/39_automake.i 1.266.1.4 755)
+++ automake.in Wed
Comparing the Automake I have at home and CVS, I found this. No idea
how this happened, but I guess I'm guilty.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* automake.in: Remove some code left from bad patches.
(&handle_dependency): Remove, for the same reason.
In
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* automake.in (&make_paragraphs): Transform BUILD, HOST and TARGET.
(&handle_tests_dejagnu, &define_standard_variables): Don't.
(&define_standard_variables): Don't transform %top_builddir% since...
* header-
Tom Tromey <[EMAIL PROTECTED]> writes:
> But right now I think we have two choices:
>
> 1. Always use `cp'
> 2. Disallow what you are trying to do.
>
> I'm inclined to #2. Good performance in `distdir' seems to be a
> popular choice. Also relative symlinks that point outside the package
> don'
%% Stephan Beal <[EMAIL PROTECTED]> writes:
sb> Please excuse the non-bug post to bug-make@..., but I didn't find
sb> another address for the make tool, and 'make@' bounced...
There's also [EMAIL PROTECTED] FWIW.
Thanks for the kudos. Some of this must be attributed to the original
invent
$(patsubst %,make, "" auto) guys (er... persons?),
For years I've worked "with" Makefiles, but never really understood
them. I've often simply felt intimidated or annoyed by their syntax
more than anything else. Recently, however, I did build tree re-org on
a project where I was prohibited fro
20 matches
Mail list logo
