Index: tests/Makefile.am
===
RCS file: /cvs/automake/automake/tests/Makefile.am,v
retrieving revision 1.271
diff -u -u -r1.271 Makefile.am
--- tests/Makefile.am 2001/04/11 04:17:21 1.271
+++ tests/Makefile.am 2001/04/12 16:49:12
@@ -
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> I still think we should have a separate class per language. This
Tom> seems cleanest by far. It might seem heavy now, but we'll be
Tom> kicking ourselves in a year if we don't do it.
I'm convinced Tom :) Really, the only obstacle is t
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> - &{$self->_finish} ();
Akim> + if (defined $self->_finish)
Akim> +{
Akim> + &{$self->_finish} ();
Akim> +}
Akim> }
Tom> I dislike this. This is a move away from encapsulation. The
Tom> objects, not the callers, ou
| I had the same problem, when I used the LDFLAGS in Makefile.am
| Running automake I get the same mystrious message.
|
| src/foo/Makefile.am:6: LDFLAGS multiply defined in condition TRUE
| LDFLAGS (User, where = 6) =
| {
|
| TRUE => -export-dynamic
| }
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I'm very surprised by:
Akim> +EXPECT = `if test -f $(top_builddir)/../expect/expect; then \
Akim> ++
Akim> +echo $(top_builddir)/../expect/expect; \
Akim> + else \
Aki
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * tests/specflags4.test, tests/specflags5.test: Remove, merged
Akim> into...
Akim> * tests/specflags3.test: here.
Ok. But why bother?
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Would it be better to use @MAKEINFO@ instead of `makeinfo' in
Akim> the else branch of
Yeah, probably. Go ahead and do this.
Akim> * automake.in (&define_program_variable): Remove.
Akim> (&scan_one_autoconf_file): Skip MAKEINF
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> The goal of the next dozen of patches is to merge the handling
Akim> of suffix rules and per object rules into a single routine and a
Akim> single file. Currently there is ext-compile and depen2, and
Akim> special cases a bit everyw
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> - &{$self->_finish} ();
Akim> + if (defined $self->_finish)
Akim> +{
Akim> + &{$self->_finish} ();
Akim> +}
Akim> }
I dislike this. This is a move away from encapsulation.
The objects, not the callers, ought to know
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_single_transform_list): Simplify
Akim> computation of $object and $this_obj_ext.
Akim> * tests/lex3.test: Merge into...
Akim> * tests/lex.test: here.
Akim> * tests/pr19.test: Improve and rename as...
Up to now, I had Automake die when it tries to redefine a user
variable. The rationale was `it must not happen, hence it's an
error'.
But it is not adequate for Automake where some `default' values may be
read _after_ the user value might have been read (of course, since
Makefile.am is loaded f
Akim Demaille [[EMAIL PROTECTED]] quoth:
*>
*>Aarg! Does it mean comp.lang.perl is really dead and should not
*>exist? I can see it from here, but its sole content is the news I
*>sent a week ago :)
Who am I to say what should exist? :) I think it was back in 1996-7 that
comp.lang.perl was
Hi Elaine!
It's good to finally have news about this issue!
| Akim Demaille [[EMAIL PROTECTED]] quoth:
| *>Jarkko, I include below a news I tried to send on comp.lang.perl, but
| *>I think it never went out of my organization.
|
| comp.lang.perl split off into comp.lang.perl.misc, .modules, .
Hi Derek, I think the patch below addresses your issue. At least, it
works on my CVS CVS. You can remove your hack :)
Tom, I'm applying it as it's a bug fix, but of course, I can revert
whatever you want me to.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* automake.in (&
I had the same problem, when I used the LDFLAGS in Makefile.am
Running automake I get the same mystrious message.
src/foo/Makefile.am:6: LDFLAGS multiply defined in condition TRUE
LDFLAGS (User, where = 6) =
{
TRUE => -export-dynamic
}
15 matches
Mail list logo
