Re: "Optional" variables ($?VAR)

Adriaan de Groot wrote:

> By default, AAP is "strict" in its variable expansions. The expression
> "$VAR" is an error unless VAR has been given a value (even an empty
> one) somewhere.  The construction $?VAR is used to indicate that the
> variable is "optional" and that if the variable has never been
> assigned a value, the expression $?VAR should expand to an empty
> string, and not give an error.
> 
> So far, so good. A departure from the old-fashioned make and shell
> semantics, where it's never an error to use $VAR.
> 
> I'm currently working on an Automake-to-AAP wedge, which is basically
> one AAP recipe that can handle most automake Makefile.am's. My testbed
> is KDE, where most of the Makefile.am's are simple groups of variable
> assignments.  Something like this is typical:
> 
> kpilotTest_SOURCES = kpilotConfig.cc \
>         logWidget.cc pilotComponent.cc \
>         hotSync.cc internalEditorAction.cc interactiveSync.cc \
>         logWidgetDCOP.skel \
>         syncStack.cc \
>         main-test.cc
> kpilotTest_LDADD        = $(LIB_KFILE) $(PISOCK_LIB) ../lib/libkpilot.la 
> $(KHEX_LIB)
> 
> Heck, that could be (part of) an AAP recipe if it weren't for one
> thing: in automake, those variables like $(KHEX_LIB) may not be
> defined; that yields empty strings in the Makefile, yet errors in AAP.
>
> So, what I'd like is a way to switch AAP's strictness for variables on
> or off within a recipe. Then I could do something like
> 
> AAP_VAROPTIONAL=1
> :include Makefile.am
> AAP_VAROPTIONAL=
> 
> in order to read in a Makefile.am. What could be nicer to introduce
> AAP to auto* and make users than as a single tool that can be
> introduced very cheaply (just the automake wedge recipe is needed)
> while providing all kinds of other possibilities as well.

I'm afraid I do not like global switches like this.  I have a lot of
experience what effect adding a global option has with Vim.  Main
problem is that the behavior of a recipe depends on the environment.
This has at least two problems:

- Not everybody reading the recipe is aware of the existence and meaning
  of the global option.  Some people will not understand how the recipe
  works: What gives an error in one situation is OK in another, without
  being clear why this happens.

- Some people will be tempted to set the option in their global Aap
  startup recipe.  Once this happens their recipes will not work for
  others.  This makes the behavior of recipes unpredictable.

Another solution would be to introduce a special command to read an
automake file.  Then it's clear that some special things happen when
reading this file.  And this command should not be used to read Aap
recipes, only for reading make-like files.

-- 
You are not really successful until someone claims he sat
beside you in school.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01