1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<title>
Autoconf Macro: patch_libtool_changing_cmds_ifs
</title>
<link rel="stylesheet" type="text/css" href="ac-archive.css">
</head>
<body>
<table summary="web navigation" style="width:100%;">
<tbody>
<tr>
<td style="width:50%;" align="center">
<a href=
"http://autoconf-archive.cryp.to/patch_libtool_changing_cmds_ifs.m4">Download
M4 Source</a>
</td>
<td style="width:50%;" align="center">
<a href="macros-by-category.html">Macro Index Page</a>
</td>
</tr>
</tbody>
</table>
<hr>
<h1>
patch_libtool_changing_cmds_ifs
</h1>
<h2>
Synopsis
</h2>
<p class="indent" style="white-space:nowrap;">
<code>PATCH_LIBTOOL_CHANGING_CMDS_IFS</code>
</p>
<h2>
Description
</h2>
<div class="indent">
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
<h2>
Author
</h2>
<p class="indent">
Guido Draheim <guidod@gmx.de>
</p>
<h2>
Last Modified
</h2>
<p class="indent">
2003-03-24
</p>
<h2>
M4 Source Code
</h2>
<div class="indent">
<pre class="m4source">
AC_DEFUN([PATCH_LIBTOOL_CHANGING_CMDS_IFS],
[# patch libtool to change $_cmds IFS from ~ to ? character
if grep "^[[_$as_cr_letters]]_cmds=.*[[?]]" libtool >/dev/null; then
AC_MSG_WARN(dnl
[patching libtool skipped - _cmds already contain question marks])
else
AC_MSG_RESULT([patching libtool to change cmds IFS from ~ to ?])
test -f libtool.old || (mv libtool libtool.old && cp libtool.old libtool)
sed -e "/^[[_$as_cr_letters]]*_cmds=/s/~/?/g" -e 's/IFS="~"/IFS="?"/g' \
-e "s/IFS='~'/IFS='?'/g" libtool > libtool.new
(test -s libtool.new || rm libtool.new) 2>/dev/null
test -f libtool.new && mv libtool.new libtool # not 2>/dev/null !!
test -f libtool || mv libtool.old libtool
fi
])
</pre>
</div>
</body>
</html>
|
