axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [


From: Waldek Hebisch
Subject: [Axiom-developer] Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox)
Date: Mon, 30 Apr 2007 14:18:15 +0200 (CEST)

Gabriel Dos Reis wrote
> As of today, we have two variables are passed in AX_FLAGS: SYS amd NOISE.
> They are all variables I would like to see them removed.  SYS, because there
> ought to be a better way of communicating the information we want to pass in
> and a better way to read it on the other side; NOISE, because there ought to
> be better way to selectively display information, but at the current
> development stage it seems like one almost always need that verbosity.
> In all cases, they are *implictly* passed to sub-processes and that is
> faithful to the idea that they need NOT be emphasized.
> 
> That is remarkably different from the uses of AXIOM and DAASE in the
> Makefile.  They are not exported through GNU Make "export", but rather set on
> the commandline that invokves the specific program they affect:  AXIOMsys.  
> I also found that, just declaring AXIOM and DAASE as exported is not
> sufficient; at some occasions they need to be set to different values.
> Consequently, I concluded that setting them on the command line for AXIOMsys
> is a better thing to do.
>

Yes.  ATM wh-sandbox still exports AXIOM and DAASE, but in my experimental
database bootstrap I need different values on each interpsys invocation
(AXIOMsys is created later).

  Bill Page wrote: 
> > 
> > Gaby, do you see any conflict between what Waldek is suggesting
> > and your current approach? Or do you see AX_FLAGS as serving
> > some other purpose not properly addressed by 'var-def.mk'?
> 
> Please see above.  The only sensible thing to do (that I planeed to do but was
> lowe priority) is to remove NOISE and restructrure some Boot files.
> I don't think anything in AX_FLAGS needs to be potentially overriden.
> I hope you see why I think AX_FLAGS should either disappear along with the
> variables it communicates
> 

I am confused by this long message.  Does the above mean that you
agree with removal of AX_FLAGS?  Or do you consider change in NOISE
functionality a blocker?

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

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