PATCH RFA: Support --enable-build-with-cxx at top level

[Ralf Wildenhues]

* Dave Korn wrote on Tue, Jun 23, 2009 at 04:55:58PM CEST:
> Ralf Wildenhues wrote:
> > * Dave Korn wrote on Mon, Jun 22, 2009 at 10:54:47PM CEST:
> >> Ralf Wildenhues wrote:
> >>
> >>> The most conservative quoting is something like
> >>>   x"$withval"

> >> ... was that both the 'x' and the $variable should be inside the quotes when
> >> using this syntax.  Did I misunderstand?
> > 
> > That is only a matter of libtool policy, not sh syntax.
> 
>   Well, don't GCC and libtool have very similar portability requirements here
> in terms of the kinds of systems they both have to run on?  I was wondering if
> any rule that's good enough for libtool shouldn't be good enough for us too?

I guess I wasn't clear in my previous statement.

There are some orthogonal issues here:

1) With
  test STRING1 OP STRING2

some old shells get confused if, after shell expansions, STRING1 starts
with a minus or is an open parenthesis.  If OP is '=' or '!=', this is
easily avoided by prepending some character to both STRING1 and STRING2.
An 'x' comes handy.

I do not know how relevant this particular issue is to nowadays shells,
but I have stumbled over similar issues with 'test' on some older
systems in the last couple of years, with varying number of arguments
to 'test'.  Note that GCC has stricter requirements as to which shells
are acceptable, than Libtool has.

2) What shell quoting style to use in scripts.
  x"$foo"

is strictly equivalent to
  "x$foo"

and the libtool test to enforce one is merely to have a more uniform
coding style.  OTOH,
  x$foo

is problematic if $foo might contain whitespace (in which case it will
expand to several words, before being passed to 'test'), and
  $foo

might in addition expand to zero words if foo is empty, which again will
confuse 'test'.

HTH.

Cheers,
Ralf