> 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 <[EMAIL PROTECTED]> > > * 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 <[EMAIL PROTECTED]> > > * 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 <[EMAIL PROTECTED]> > > * 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. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
