automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 33-dist-flavors.patch


From: Akim Demaille
Subject: Re: 33-dist-flavors.patch
Date: 21 Feb 2001 09:25:29 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)

Tom Tromey <address@hidden> writes:

> >>>>> "Akim" == Akim Demaille <address@hidden> writes:
> 
> Akim> This patch includes all the diffs of Makefile.ins, i.e., subdirs'
> Akim> Makefile have not changed.  The big change in the top Makefile.in
> Akim> comes from the fact that the so called `find complex command' is
> Akim> attached to distdir (where it belongs IMHO), rather than to each
> Akim> dist-like target.
> 
> A "top level" Makefile.in might actually be called from a higher
> directory.  Suppose I take a complete auto*-using package and make it
> a subdir of another package.
> 
> This might affect this code.  I don't remember.  

I can't see how :(  There is definitely some cpu wasted in this case,
given that the inner topmost Makefile _and_ the outer topmost Makefile
will both run the complex find command, but it is not wrong.

In fact, given the name of the target, it seems to me that distdir is
not reached until the find command is run: it really belongs to
there.  So, by a rather naive argument I agree, it can't be wrong.

> But we have to be sure that this change doesn't cause problems in
> this scenario.

I fail to see where such a thing can happen.   Maybe you are think to
some Cygnus tree or something?  I don't know it, and lack of
imagination :)

> If it does cause problems (I haven't looked) then one solution would
> be to introduce an intermediate target:
> 
>     dist: _am-dist-intermediate
>     _am-dist-intermediate: distdir
>       find ...
> 
> Could you look at this first?
> If there are no problems then go ahead and commit it.

Maybe I'm taking too much freedom here, feel free to flame me if I did
wrong, but I'm going to apply the patch now anyway because

1. you didn't actually refuse it, you seem to like it but be afraid of
   some related issue.

2. I fail to see how it could actually do something wrong.

3. If there is actually something wrong, then we will have the
   opportunity to write a test case, document the requirement, fix the
   code (very easy, you already gave the fix).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]