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

[Bill Page]

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

> 
> > The second extra problem is that AX_FLAGS is new code,
> > so may trick potential readers to think that its use
> > is right thing to do.
> 
> Excuse me, but that is bullshit. 
> 

I fail to see how either of these last comments add anything
substantial to this debate. :-( So let me try to get us past
this point.

Earlier Waldek wrote:

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

> 
> 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'. And the information
about which variables these are is not available locally in the
make file but rather determined by how the make file is called.

Gaby annouced 'var-def.mk' in 'ChangeLog.build-improvements':

> 2006-08-26  Gabriel Dos Reis  <address@hidden>
>
>        * config/var-def.mk: New file.  Hold boileplate definition
>        of standard Autoconf/Automake variables.
> ...

The GNU coding standards include conventions for Makefile
variables:

http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html#Makefi
le-Conventions

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)

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.

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

Regards,
Bill Page.