Hi,
I'm trying to do something, of which there is a very similar example in
the automake docs at
http://www.gnu.org/manual/automake/html_mono/automake.html#SEC11
However, despite my efforts, I can't seem to convert the example into
what I want.
Essentially, I want to build two binaries
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> gcj.test fails unexpectedly in the CVS automake on RedHat 7.1.
Thanks, I fixed this.
Tom
> "David" == David Kirkby <[EMAIL PROTECTED]> writes:
David> The difference I'm trying to overcome, is that when building
David> rect_in_rect, RECT_IN_RECT should be defined. Whereas when
David> building circ_in_circ, then instead of RECT_IN_RECT being
David> defined, CIRC_IN_CIRC would be de
-my %clean_files;
-grep { $clean_files{"$infobase.$_"} = 1} @clean_suffixes;
+# FIXME: I don't understand why, but I can't use "$infobase.$_" => 1.
+my %clean_files = map { "$infobase" . ".$_" => 1 } @clean_suffixes;
grep { delete $clean_files{"$infobase.$_"} } @syncodein
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> gcc3 very nearly does exactly what automake wants in terms of
Tom> dependency tracking.
Tom> I think that ideally automake should recognize this and avoid
Tom> using depcomp when it discovers that the user is using gcc3. In
Tom> this si
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> Right now m4/depend.m4 sets
Tom> am_cv_OBJC_dependencies_compiler_type=gcc whenever doing
Tom> dependency tracking for OBJC.
Tom> I think this is wrong. We might be running gcc3, which we ought
Tom> to prefer.
Err, I never looked at th
Index: TODO
--- TODO Wed, 07 Mar 2001 21:02:27 +0100 akim (am/f/42_TODO 1.7 644)
+++ TODO Sun, 13 May 2001 10:32:37 +0200 akim (am/f/42_TODO 1.7 644)
@@ -9,9 +9,6 @@
we need a document describing automake from the end user's point of view
eg describe INSTALL_HEADER there, among other things
-
On Sunday 13 May 2001 2:10 am, Tom Tromey wrote:
> > "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes:
>
> Steve> P.S. I have no clue if this affects automake CVS. But a
> Steve> 1.4-p2 would be appreciated!
>
> I don't plan to do it, but if you can convince Gary it is fine with
> me.
I found it strange that this code (head of the module in cvs) seemed
to work fine when I ran `make check' but failed right away after I'd
installed it in a clean hierarchy and tried to use it.
2001-05-14 Jim Meyering <[EMAIL PROTECTED]>
* automake.in (macro_define): Change one remainin
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Tom> Right now m4/depend.m4 sets
Tom> am_cv_OBJC_dependencies_compiler_type=gcc whenever doing
Tom> dependency tracking for OBJC.
Akim> Err, I never looked at this code, and I have no idea how it
Akim> works... Why do you ask for objc, b
> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> 2001-05-14 Jim Meyering <[EMAIL PROTECTED]>
Jim>* automake.in (macro_define): Change one remaining use of
Jim>`variable_dump' to `macro_dump'.
I'm checking this in.
I think you could have simply checked this in under the `obv
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> grep { delete $clean_files{"$infobase.$_"} } @syncodeindexes;
Akim> This last one (not patched), I'm not sure how to write it elegantly.
Won't s/grep/map work here?
I think we should adopt a rule of only using grep where we u
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> The latest CVS Automake works fine for
Robert> --enable-dependency-tracking, but when
Robert> --disable-dependency-tracking is specified it's still choking.
Robert> .cxx.o:
Robert> source='$<' object='$@' libtool=no
Rob
I removed the `Automake' directory from the cvs repository.
Usually I don't do this sort of thing, but we were getting bug reports
about it even though it is dead.
If you have automake checked out you might need to edit your Entries
file to remove reference to the directory. A clean checkout wou
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
I'm working on moving *.am into lib/am right now.
It will be done soon.
Akim> This is my proposal for this move.
This patch is ok.
Akim> * automake.in ($pkgdata_dir): Rename as...
Akim> ($libdir): this.
Akim> ($am_dir): Remove, re
Akim --
The *.am move also requires a Makefile.am update.
Maybe I'll just check in the whole mess, as I am working on it anyway.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I don't feel comfortable with not pushing our modules first in
Akim> the list. I sure know there is Automake:: in front of them, but
Akim> it just makes me nervous.
I'm not too concerned about this. If we do run into a failure we
Try removing
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>> Yeah, I still have a few of your patches sitting in my mailbox.
Derek> Well, when you get around to it, this one should take the place
Derek> of my last depcomp patch. I fixed tests/depcomp, tidied the
Derek> ChangeLog based on the s
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
This is a report from a while back.
Robert> I'm testing the CVS MLB Libtool with current CVS Automake and
Robert> Autoconf. I've found that dependency tracking doesn't work
Robert> because the depcomp script is copied into the auxiliar
I've moved all the *.am files into lib/am. I also move a lot of
helper files into lib/. This turned out to be a *lot* more work than
I thought it would be.
The result still isn't perfect. Right now we have INSTALL and COPYING
duplicated: they are both at the top level (for automake itself) and
> "edward" == edward <[EMAIL PROTECTED]> writes:
Sorry about the delay in my reply.
edward> noinst_PROGRAMS = foo
edward> foo_SOURCES = foo.i
edward> automake will die with:
edward> + perl ../../automake --amdir=/usr/beta/src/automake/tests/.. --foreign
edward> -a
edward> Use of uninitiali
> "edward" == edward <[EMAIL PROTECTED]> writes:
edward> On systems with make programs which delete intermediate
edward> targets (including cygwin), I expect pr19 to fail with foo.c
edward> not found.
I thought we circumvented this by emitting dependencies so that
intermediate files weren't
23 matches
Mail list logo
