Do a `grep "^[a-z]*_cmds=" libtool` - these are "subroutines"
encoded by libtool.m4 into the generated libtool script. Since
libtool assumes that there is no subroutine-facility in the
shell invoked, these are not actually subroutines, but actually
a "list of commands". This looks correct, but the command
separator is not ";" - it is "~", the tilde character.
Now, grep again, look for `grep 'IFS="~"' libtool` and see
that libtool scripting uses a for-loop on the command-list,
i.e for cmd in $some_cmds. This works correctly when the
IFS was modified, where IFS stands for "input field separator"
which is whitespace characters by default.
The problem: I have some real-world filesystems where there
are directories using "~" inside of them, to be more to the
point, it is a change control management software that uses
source repositories of the form "path/master/project~version/src"
and libtool has the tendency to resolve any symlinks so that
it will paste such path into the $_cmds script when it gets
evaluated a number of times.
This script is a workaround: I do not know why the ";" was
not chosen as the IFS, perhaps it has some weird interactions
in some shells since it is also the default record separator
being one time bigger in context than the argument separator.
I have made good success however with using "?" as the IFS,
since there is no path-name that uses a question mark, and
there is no _cmds ever around that uses "?" for some thing.
Oh yes, there are some usages of "*" to match shell-wise at
the output file of some tool, so that might have triggered
the choice to not use "?" in the first place - but in real
life it never occured that a _cmds script was created that
has gone to use "?". And so, this ac-macro exchanges the
s/~/?/g in configured _cmds variables and replaces all
occurences of s/IFS="~"/IFS="?"/ - and it all works smooth now.
@= guidod@gmx.de
@$Id: patch_libtool_changing_cmds_ifs.m4,v 1.3 2003/03/25 20:04:40 guidod Exp $