[Top][All Lists]

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

Re: [Axiom-developer] Re: [Axiom-commit] SVN: axiom: [508] branch

From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Re: [Axiom-commit] SVN: axiom: [508] branches/wh-sandbox
Date: Sun, 29 Apr 2007 19:14:58 -0500 (CDT)

On Mon, 30 Apr 2007, Waldek Hebisch wrote:

> Gabriel Dos Reis wrote:
> > AX_FLAGS presents far less technical problems than ENV does; in fact,
> > I would be very much interested in the problems you see with AX_FLAGS
> > that is not present with ENV.  
> > 
> > I asked for technical reasons, the serious reason I have been offered
> > is that "you dislike it more than ENV".  THAT reads "gratuituous"
> > difference in my book.
> > 
> First, I see no problem with name: since we can not use ENV changing
> it to AX_FLAGS is OK.  My basic objection is that AX_FLAGS is redundant.
> We already have mechanizm to propagate values to subdirectories:
> we use

Well, if that is the basis of your objection, then it has no foundation.
The purpose of AX_FLAGS is not to propagate values to subdirectories.

The purpose of AX_FLAGS is to propagate values to *sub-processes*, much

Until very recently, that is a very simple, reliable way of communicating
values without duplication.

>  So AX_FLAGS establishes parallel chanel,
> which has significant potential for bugs and confusion.
> The problem I see in writing
> make AX_FLAGS
> (as opposed to)
> AX_FLAGS make
> is that we override thing in Makefile. But we are effectively
> "broadcasting" AX_FLAGS down which looks like abuse of mechanizm
> designed for something else (that is allowing default in
> Makfile but sometimes taking alternate values).

That is an abuse only if you're mistaken about the purpose.

> The second extra problem is that AX_FLAGS is new code, 

Excuse me, but that is bullshit. 

-- Gaby

reply via email to

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