> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Akim> Yep, I did not unroll the whole thinking, but indeed, another
Akim> means to reach the expected effect consists in using -I and tell
Akim> automake not to play with @INC, i.e., since we want to _tell_
Akim> automake not to (as opposed to
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> Shouldn't the prototype for file_contents_internal read `($$%)'?
Yep, definitely. Thanks!
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> I noticed after uploading that you haven't made diffs or xdeltas
Gary> for your other releases. I can delete the new diff and xdelta
Gary> if you like.
You can leave them. Historically automake releases have been
characterized by
On 8 May 2001, Akim Demaille wrote:
> Does anybody know something better than patch(1) when a patch fails?
> I often have to struggle hard to understand why a patch does not
> apply, patch(1) just rejects it.
Paul Mackerras (formerly of Linuxcare AU) has a program called dirdiff out
there. It di
On Tuesday 08 May 2001 11:39 pm, Tom Tromey wrote:
> > "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>
> Gary> Let me know if you are happy with the results (or if there are
> Gary> any other obvious fixes you would prefer to apply first) and I
> Gary> will roll up the release and put i
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Let me know if you are happy with the results (or if there are
Gary> any other obvious fixes you would prefer to apply first) and I
Gary> will roll up the release and put it up on ftp.gnu.org.
It looks good to me.
There is a releas
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...
Akim> * tests/lex3.test: this.
Feel free to check this i
Hi.
On Monday 07 May 2001 12:38 am, Tom Tromey wrote:
> > "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>
> Gary> I guess that it might be advantageous to have a call for
> Gary> bugfixes email incase there are any other pet bugfixes people
> Gary> might like backported to a stable rel
Pavel> Un-flattenning Automake is probably a good idea, but the
Pavel> history is a serious concern, especially considering that the
Pavel> output of "cvs annotate" will be affected.
My plan is to copy the `,v' files on the repository and then remove
all the tags in the copies. Then I will `cvs
Akim> * automake.in (@objects): Remove, unused.
Akim> Remove all the code related to it, and to former `$(OBJECTS)'.
Ok, thanks.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I would like to move the documentation into doc/ in Automake.
Akim> OK with that? Same problem as for *.am files, Tom, we need to
Akim> move them on the CVS server if we want to keep the history.
I would like to keep the history.
I
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> + return 1 if $comp eq 'TRUE';
Akim> + return 0 if ! defined $cond_vals{$comp};
Akim> I don't understand why you had TRUE here. I mean, it seems to
Akim> me it's a `next' not a return. Conditionals are conjunctions,
Akim> not disj
Russ> Well, the effect of -I is just to add things to @INC, so since
Russ> you're modifying @INC with Perl code, one can potentially take
Russ> the effects of -I into account and not override them. The
Russ> question is more the best way of doing that.
Akim> Yep, I did not unroll the whole think
On Tuesday 08 May 2001 8:51 pm, Tom Tromey wrote:
> > "Gary" == gvv <[EMAIL PROTECTED]> writes:
>
> Gary> Branch: branch-1-4
> Gary> * configure.in (AM_INIT_AUTOMAKE): Bump version to 1.4.1.
>
> This won't work. `1.4.1' is an alpha version according to our rules.
> For inst
> "Gary" == gvv <[EMAIL PROTECTED]> writes:
Gary> Branch: branch-1-4
Gary> * configure.in (AM_INIT_AUTOMAKE): Bump version to 1.4.1.
This won't work. `1.4.1' is an alpha version according to our rules.
For instance this means README-alpha will be in the distribution.
Instead, could y
Akim> | Akim> * automake.texi (Conditionals): Document it.
Tom> | Ok.
Tom> | Could you update automake.texi to reflect this change?
Akim> :)
Oops. I thought I looked at the patch and didn't see a .texi change
there. Thanks.
Tom
Shouldn't the prototype for file_contents_internal read `($$%)'?
Tom
I went through all the automake PRs recently. I've changed the
`priority' field to reflect what I think are the 1.5 release
requirements: if a PR has `high' priority then it should be fixed for
1.5.
Feel free to make a case for changes to this prioritization if you
think any are required.
Tom
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> FYI: We currently use $(SOURCES) for tags (btw tag generation is
Tom> an ugly bit of code...), but I don't think we use $(OBJECTS) at
Tom> all. We should simply remove it.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> But if you value history of individual files more than that of
Pavel> the project I suggest (as my second best preference) copying
Pavel> those files in the repository and then removing the old files
Pavel> using "cvs remove". This
Hello, Akim!
> | Don't you know that Automake has its
> | documentation in the top-level directory?
>
> I would like to move the documentation into doc/ in Automake. OK with
> that? Same problem as for *.am files, Tom, we need to move them on
> the CVS server if we want to keep the history.
Un
Akim Demaille <[EMAIL PROTECTED]> writes:
> Well, indeed it can help when it's the context that changed, but if the
> difference in the core of the patch I don't think it makes a difference.
> I'm not looking for a way to have patch be more permissive, I want it to
> tell me what makes my patch
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Closing in on the one-month anniversary for this one... Lars J
Thanks, applied!
| > Pavel> + elsif (/^\@def(code)?index (\w+)/)
| > Pavel> +push @clean_suffixes, $2;
Yes Tom, I was not aware of the existence of defindex! Thanks for
this patch Pavel.
| > My understanding is that here $1 will not necessarily be defined, but
| > $2 will always be defined. Is th
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> I think the appropriate fix is to move processing for these
Tom> targets out of texinfos.am and into subdirs.am. Akim, what do
Tom> you think?
I did not really analyze the issue yet, but your proposal goes in the
opposite direction I'm
Jim> * m4/strip.m4: Fix a typo: s/\$\$/$/.
Pollux> This issue should disappear with the following pending patch.
Pollux> http://sources.redhat.com/ml/automake/2001-03/msg00129.html
I agree with this patch. I also agree with the one documentation one,
http://sources.redhat.com/ml/automake/2001
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> Well, the effect of -I is just to add things to @INC, so since
Russ> you're modifying @INC with Perl code, one can potentially take
Russ> the effects of -I into account and not override them. The
Russ> question is more the best way o
Akim Demaille <[EMAIL PROTECTED]> writes:
> No, it's not the only problem. The whole problem is that the definition
> of @INC inside automake is performed after -I, hence -I will always be
> overridden, and therefore chances are high to test uninstalled automake
> with installed am files etc.
W
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1067
diff -u -r1.1067 automake.in
--- automake.in 2001/05/05 21:16:36 1.1067
+++ automake.in 2001/05/06 00:40:00
@@ -5487,13 +5487,16 @@
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I think the current solution is ugly, very much agreed, but much
Akim> safer.
Something which seems nicer would be to use `perl -e' to define
perllibdir instead of using %ENV.
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> I don't like perllibdir. If it exists only for the sake of the
Tom> test suite then I'd prefer we just add a -I in the test suite.
Tom> Maybe that means we have to make defs from defs.in? That would
Tom> mean an ugly change in the test
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Tom, I'm done with all my patches (yeeeha!). I'm now ready to
Akim> move the am files. But given that you probably want to keep
Akim> their CVS history, I think you'll have to do that.
Akim> If you don't care, I can handle this vi
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Hi Lars!
: I often have to struggle hard to understand why a
: apply, patch(1) just rejects it.
Lars> Doesn't --fuzz=num help?
Well, indeed it can help when it's the context that changed, but if
the difference in the core of the patch I do
Tom, I'm done with all my patches (yeeeha!). I'm now ready to move
the am files. But given that you probably want to keep their CVS
history, I think you'll have to do that.
If you don't care, I can handle this via cvs remove + add.
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Still getting closer to what Tom doesn't want: the read_am_file
Akim> removal. I would be lying if I pretended that this removal was
Akim> easy: pretty many weaknesses in file_co
On Tue, May 08, 2001 at 02:43:43PM +0200, Akim Demaille wrote:
: Does anybody know something better than patch(1) when a patch fails?
: I often have to struggle hard to understand why a patch does not
: apply, patch(1) just rejects it.
Doesn't --fuzz=num help?
Lars J
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_single_transform_list): Simplify
Akim> computation of $object and $this_obj_ext. * tests/lex3.test:
Akim> Merge into... * tests/lex.test: here. * tests/p
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> I don't really think these changes are improvements. The
Tom> cumulative effect is that if Cygnus mode changes we have to
Tom> search all over the place to make the change. Why do you prefer
Tom> this?
Still the same idea: automake is
| > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
|
| Akim> Support `if !COND', `else COND', `end COND'.
| Akim> * automake.texi (Conditionals): Document it.
|
| Ok.
|
| Could you update automake.texi to reflect this change?
:)
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> Is there any reason not to simply delete objc.test?
I meant to implement a quick hello world in objc. But, agreed, this
is a completely different test.
Does anybody know something better than patch(1) when a patch fails?
I often have to struggle hard to understand why a patch does not
apply, patch(1) just rejects it.
For instance one of my patches produced a
~/src/am % wc automake.in.rejnostromo 14:42
27
Gary V Vaughan <[EMAIL PROTECTED]> writes:
> I became confused when I found an empty automake project on savannah.
> We probably ought tp remove it from there I guess...
I was confused by that too when I started looking at Savannah, but after
looking a bit closer, it appeared that someone had si
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> Ok. Thanks once again for doing all this work.
:) Thanks to you, it's my pleasure!
On Sat, May 05, 2001 at 03:18:56PM -0600, Tom Tromey wrote:
> How do you define SUBDIRS?
By condtionally defining a set of variables, and then defining SUBDIRS in
terms of each of these conditional variables. I attach the Makefile.am in
question, for reference.
> Please send a ChangeLog entry wi
44 matches
Mail list logo
