[Top][All Lists]
[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
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox, (continued)
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox, gdr, 2007/04/27
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox, Waldek Hebisch, 2007/04/27
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox, Gabriel Dos Reis, 2007/04/27
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox, Waldek Hebisch, 2007/04/27
- RE: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox, Bill Page, 2007/04/28
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox, Waldek Hebisch, 2007/04/29
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox, Waldek Hebisch, 2007/04/29
- Re: [Axiom-developer] Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox, Gabriel Dos Reis, 2007/04/29
- [Axiom-developer] AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox), Bill Page, 2007/04/30
- [Axiom-developer] Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox), Gabriel Dos Reis, 2007/04/30
- [Axiom-developer] Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox),
Waldek Hebisch <=
- [Axiom-developer] Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox), Gabriel Dos Reis, 2007/04/30