[Axiom-developer] Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox)

[Gabriel Dos Reis]

On Mon, 30 Apr 2007, Bill Page wrote:

> > Waldek Hebisch wrote:
> > ...
> > > My basic objection is that AX_FLAGS is redundant.
> > > We already have mechanizm to propagate values to
> > > subdirectories: we use var-def.mk.
> > > So AX_FLAGS establishes parallel chanel, which has
> > > significant potential for bugs and confusion.
> > 
> 
> Gabriel Dos Reis wrote:
> 
> > 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 like MAKEFLAGS.
> 
> I think there is no substantive difference between
> "propagate to subdirectories" and "propogate to sub-
> processes" since I do not know what the former expression
> could mean if not the latter.

I understand propagating to subdirectories means that Makefile in
subdirectories see the value of the variable.  Propagating to sub-processes
means that processes launched by Make either directly or recursively see the
value of the variable.  That is not the same thing.  
Granted the version of Axiom build-improvements branched from was using the
latter to simulate the former in most cases, but there is a distinction to be
made ansd config/var-def.mk was partlt created to address that.


> It seems clear to me that
> provided the information is static (i.e. determined at
> configure-time) it could be communicated to sub-processes
> by either mechanism.

If you define the variable only in the Makefile, you don't communicate it to
sub-processes. 

[...]

> > The problem I see in writing
> >
> > make AX_FLAGS
> > 
> > (as opposed to)
> > 
> > AX_FLAGS make
> 
> [ which defines process environment variabes thar are inherited
> as variables in 'make' ]

Notice that if you do either of those, you are communicating variables to
sub-processes.

> > 
> > 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).
> 
> Reading 
> 
> http://www.gnu.org/software/make/manual/make.html#Overriding
> http://www.gnu.org/software/make/manual/make.html#Override-Directive
> 
> it seems to support the notion that passing arguments to make
> is intended to suport overriding of default values. I agree
> that it could potentially lead to confusion because any values
> of these variables set locally in the make file are ignored
> unless they are explicitly coded as 'override'.

Before people start pulling out big words like "override" and "confusing",
they should probably look at the variables being passed in AX_FLAGS and 
elaborate on why they believe that any value set locally is ignored and why we
should not do that.

[...]

> And AX_FLAGS was introduced here:
> 
> > 2006-12-06  Gabriel Dos Reis  <address@hidden>
> >
> >        * config/var-def.mk (AXIOM, DAASE, SYS): Don't export
> >        through GNU Make extension "export".
> >        (AX_FLAGS): New.  Use for "exporting" variables.
> > ...
> 
> But var-def.mk has also been extended to include axiom-specific
> variables. For example in 'var-def.mk' we find:
> 
>   ## Where to find Axiom data bases.
>   DAASE = $(axiom_src_datadir)

Some variables like AXIOM, DAASE, SYS, etc. need to be visible to
sub-processes (e.g. AXIOMsys), not just Make.  A "natural" way to do 
that is to declare them exported.  Ideally, I would like to see that piece of 
information declared in one place once for all.  The version of Axiom
build-improvements branched off used the ENV variable, which proved to be
problematic under some circumstances.  Then I spend trimming down the content
of that variable: many of them did not need to be exported.  They were moved
to config/var-def.mk which I also created to hold variables that should be
present in each Makefile.  At some point, in a quick hack, I used the GNU Make 
extension "export" for some variables that truly need to be exported to
sub-processes.  When testing on *BSD and solaris, I removed the use of
that extension.  At that time, I still had a hope that we could cramm the
makefiles so that it could work with several Make programs.

Please note that, at the exception of NOISE, none of the involved variable is
one that will be set by user at whim.  In fact, they are things the user
should not even know about.  I would like to eliminate NOISE.

Please, also note that just setting those variables in the Makefile is not
sufficient.  They need to be exported.

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.

Please notice that I do not invoke make as

   AXIOM=...  DAASE=... make ...

because I don't think that is the appropriate thing to do.  Those variables
affect only AXIOMsys and depsys.  They are scheduled for disappearance (though
I plan communicating them through AXIOMsys options).

> 
> In  ChangeLog.build-improvements there is some evidence that
> Gaby has already started to use 'var-def.mk' in the manner
> suggested by Waldek:
> 
> > 2006-12-09  Gabriel Dos Reis  <address@hidden>
> >
> >        * config/var-def.mk (AX_FLAGS): Don't pass DAASE.
> 
> I think that Waldek is claiming that all variables should be
> handled this way and that passing AX_FLAGS is unnecessary, thus
> permitting all make variables to potentially be overriden.

Why would you ever want to override SYS?

> 
> 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

-- Gaby