Re: "Optional" variables ($?VAR)

On Tuesday 19 August 2003 12:13, you wrote:
> Adriaan de Groot wrote:
> > On Sunday 17 August 2003 16:52, Bram Moolenaar wrote:
> > > 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:
> >
> > Objections noted.
> >
> > > Another solution would be to introduce a special command to read an
> > > automake file.  Then it's clear that some special things happen when
> >
> > But that's even more bloat and code to maintain for something you
> > don't really want at all. If you want AAP to replace automake and
> > make, then you'd prefer people to write AAP recipes instead of
> > automake files and then running AAP over top of them. Perhaps a
> > transitioning-from-automake-to-AAP tutorial would be more useful (I'll
> > write one once I figure out just how :) )
>
> Very often you find yourself in the situation that you are working with
> an existing (big) project that uses make/automake/etc.  When you want to
> start using Aap and other developers still use the old tools you can't
> just convert files to Aap recipes, the old files will remain being used.
> When making changes the two versions drift apart.  I would prefer to do
> the conversion on the fly in this situation.  That's where the "read
> automake file" command would be useful.

Sure. In most cases, :include am-wedge.aap is good enough (this is my 
automake-to-aap wedge, which does an :include Makefile.am and knows enough 
about automake to convert most of the targets to their AAP equivalents). 


> If you want to convert a project from using Makefiles to recipes then a
> tool to do part of the conversion automatically would be useful.  It
> doesn't need to do much more than putting ":sys " in front of shell
> commands.  I don't think you would want to use $?VAR in place of $VAR

[Still talking about _auto_makefiles.] One construction that comes back 
several times is for "variants" based on configure (autoconf) results. These 
look like

if include_malconduit
MAL_SUBDIR = malconduit
endif

where include_malconduit is defined by configure - and stored in a confusing 
place. As far as I can tell, grepping for 'include_malconduit_FALSE.*#' in 
config.status is all you can do (if found, include_malconduit is true).

Another is normal makefile targets, like this one:

messages: rc.cpp
        $(EXTRACTRC) *.rc *.ui */*.ui >> rc.cpp
        $(XGETTEXT) *.h *.cpp */*.cpp */*.h -o $(podir)/kaddressbook.pot

this construction falls under normal Makefile-reading rules.

A third is file inclusion:

include ../admin/Doxyfile.am

this inclusion mechanism is independent of GNU or BSD make.


> Since Aap intends to do everything that make does, adding a command that
> includes a Makefile could be useful.  Especially when we explain the
> restrictions.  For now I think we can read quite a few Makefiles when
> supporting only a few things:
>
> - Assume $?VAR everywhere.
> - Put ":sys " in front of all shell commands.  Remove '-' and '@'.
> - Interpret "include file" as ":include file".

AAP's include reads everything relative to the current recipe, while make's 
include is, IIRC, relative to the file being processed (recipe or included 
file, it matters not). This makes nested includes work differently in AAP 
than in make. And unfortunately, BSD make uses ".include" (possibly with <> 
as well) and GNU make uses plain "include".


-- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <[email protected]>
     Key fingerprint = 934E 31AA 80A7 723F 54F9  50ED 76AC EE01 FEA2 A3FE



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