Re: libtool updates

On Thursday 02 October 2003 11:39, you wrote:
> recipe for another KDE program should be simple.  Should the kde module
> also be included with Aap?

Probably. It still needs a lot of documenting and some more magic, though. I 
haven't worked on interface compilation and other multi-step compilations 
with "fake suffixes" and the like. I need to get Qt working properly first :(

> In the search for a valid libtool I don't see why /bin/false is in the
> list.  I assume it was there because you copied this from a shell
> script, I'll remove it for now.

I forget why I did that too. If no libtool is found, then the import should 
fail with an exception.


> It is a bit unusual to use $libtool instead of $LIBTOOL.  Was there a
> specific reason for this?  The documentation should mention that
> m_libtool.libtool holds the name of the program.

Originally I used $LIBTOOL, then though that was confusing wrt. environment 
variables and local settings. At one point I had

	libtool = $?_recipe.LIBTOOL
	@if not libtool:
		libtool = $_top.LIBTOOL

or something like that, before you added the funky module-variable-scoping.


> Another solution would be to invoke the tool-specific compile action
> with a prefix argument, since it appears that libtool prepends a few
> things to the compile command without changing it otherwise.  Something
> like $CMD_PREFIX or a cmd_prefix attribute on the action.  Would that
> work?

yes, that would work. libtool (like depcomp) is intended to be prefixed to a 
"normal" compile command, and then it mutates that command to produce libtool 
output instead of normal stuff (in the case of C++ compiles with gcc, it 
changes -o <foo>.o to -o .libs/<foo>.o).

-- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <[email protected]>
            If the door is ajar, can we fill it with door-jamb?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf