Re: (tutorial) Changing the type of a program

Adriaan de Groot wrote:

[This defenitely belongs in the -develop list, let me copy it there]

> > Despite your well written explanation, we can make the default behavior
> > simpler: When the user assigns something to $LIBTOOLLIBS the default
> > link argument can use $LIBTOOL instead of $LD:
> 
> Where you say "simpler" I'd say "smarter", and I'd hesitate putting too
> much smarts into one rule. After all, the general principle of using
> filetypes to select the action is important in AAP, and what happens if
> the libtool arguments change, or, heaven forbid, someone realizes that
> --tag=CXX is for compiling libtool programs composed of C++ libtool object
> files, and that a different rule is needed for C programs? See, you'll
> just keep adding complications to the default rules, while making separate
> filetype-distinguished rules is more flexible.  Then someone could
> distribute a kde.aap recipe that defines all the compile and build actions
> relevant to building KDE applications, without disturbing the defaults.

We have two conflicting goals here: We want the actions to be doing one
thing only and be easy to understand, while at the same time the things
that many people use should work automatically.

I agree that having a separate "build libtoolexe" action for building
(linking) with libtool is logical.  How do we tell Aap to use this
action instead of the default "build" action then?

I suppose your method of setting the filetype is appropriate.  The user
needs to know about this and it's a bit more complicated than setting
the $LTLIBS variable, but it's also less obscure.

	:program myprog {filetype = libtoolexe} : myprog.c


I can add a "build libtoolexe" action to the default.aap recipe.  That
will make it easier for people to use it with a simple recipe.  But
libtool takes quite a few arguments, thus we need to decide how to make
these available to the user.

How about something like this:

# default libtool command, user may change this
LIBTOOL ?= libtool --silent --mode=link

:action build libtoolexe
    # Allow using an action from a plugin tool.
    @if _no.get("BUILD_LT_ACTION"):
	:do $BUILD_LT_ACTION {target = $target} $source
    @else:
	tag = $?LTTAG
	@if not tag:
	   # No libtool tag specified by the user.
	   # If the objects were compiled with $CXX, we need to use the same
	   # for the linker.
 	   @if _no.USECXXLD == "yes":
	      tag = --tag=CXX
 	   @else:
	      tag = --tag=C

	ld = $?LD
	@if not ld:
	   # No linker specified by the user.
	   # If the objects were compiled with $CXX, we need to use the same
	   # for the linker.
 	   @if _no.USECXXLD == "yes":
 	      ld = $CXX
	      flags = $CXXFLAGS
 	   @else:
 	      ld = $CC
	      flags = $CFLAGS

	:buildcheck $OPTIMIZE $?DEBUG
	:sys $LIBTOOL $tag $ld $LDFLAGS `cflags_normal()` $?flags -o $target $source $?LIBS $?LTLIBS


Again the question pops up if we should use $CFLAGS or $CXXFLAGS for the
linker command.  Perhaps we can drop that and tell the user to use
$LDFLAGS when he needs to specify flags for the linker.  That also
solves the problem that we don't know which one to use when $LD has been
set by the user.

-- 
hundred-and-one symptoms of being an internet addict:
1. You actually wore a blue ribbon to protest the Communications Decency Act.

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