Re: recent x changes, solaris compiler-options-with-spaces,

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Jun 04, 2012 at 09:00:35PM -0400, Greg Troxel wrote:
> 
> (Recently wiz@ updated many xorg things, and several people are having
> issues.  Apparently there is some discussion on pkgsrc-changes@, but I
> think these issues are important enough to warrant tech-pkg@ discussion
> - my view is that pkgsrc-changes-d is really for minor followups about
> non-controversial not-particularly-important things.)
> 
>   Thmoas wrote:
> 
>   On Mon, Jun 04, 2012 at 11:23:50AM +0200, J?rn Clausen wrote:
>   > What's the status of this problem? I get the same error
>   > 
>   > checking if cc -std=gnu99 supports -Werror=implicit... no
>   > checking if cc -std=gnu99 supports -errwarn=E_NO_EXPLICIT_TYPE_GIVEN
>   > -errwarn=E_NO_IMPLICIT_DECL_ALLOWED... eval: 1: Syntax error: Bad
>   > substitution

That is two compiler options that should be treated separately.

> Speaking as an old-school unix user, it seems bizarre of Solaris to have
> compiler options with spaces in them; no one who actually writes code
> and uses command-line tools would do that.  But when reading configure
> (in libfontenc), it seems the problem is that two distinct error options
> are tested at the same time, rather than separately.  This seems
> irregular in and of itself.  It seems the point is to replace
> -Werror=implicit with two -errwarn invocations, but I don't see why the
> configure code can't simply try to enable each error flag separately,
> and use the ones that are ok.

Well, doing it in one go saves the number of times the compiler is
executed.

> Do we already have an easy mechanism to require a different sh for
> running configure?  My view is that the 5.1 sh failing is a clue that
> the configure code is too hairy (even if the 5.1 sh is found to be
> buggy).
> 
> The actual issue is:
> 
> + eval ${xorg_cv_cc_flag__errwarn_E_NO_EXPLICIT_TYPE_GIVEN 
> _errwarn_E_NO_IMPLICIT_DECL_ALLOWED+:} false
> eval: 1: Syntax error: Bad substitution
> 
> 
> Is it really legitimate to expect
> 
> eval \${a b}
> 
> to evaluate the value of a variable with name "a b"?

No, the shell doesn't support spaces in variable names, ssomething has
already changed a lot of invalid chars to '_' in that name, it would
need to change ' ' as well.

        David

-- 
David Laight: david%l8s.co.uk@localhost