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
|
# =======================================================================================
# https://www.gnu.org/software/autoconf-archive/ax_patch_libtool_changing_cmds_ifs.html
# =======================================================================================
#
# SYNOPSIS
#
# AX_PATCH_LIBTOOL_CHANGING_CMDS_IFS
#
# DESCRIPTION
#
# 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 occurred 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
# occurrences of s/IFS="~"/IFS="?"/ - and it all works smooth now.
#
# LICENSE
#
# Copyright (c) 2008 Guido U. Draheim <guidod@gmx.de>
#
# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved. This file is offered as-is, without any
# warranty.
#serial 9
AU_ALIAS([PATCH_LIBTOOL_CHANGING_CMDS_IFS], [AX_PATCH_LIBTOOL_CHANGING_CMDS_IFS])
AC_DEFUN([AX_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
])
|
