configure WARNINGS

[David Holmes]

 > Note the extra spacing after =32.

Actually you won't notice it because Thunderbird auto-corrected it :( 
Take my word for it there's three spaces between =32 and the next -

:)

David

On 25/10/2012 11:43 AM, David Holmes wrote:
> On 24/10/2012 10:06 PM, Magnus Ihse Bursie wrote:
>> On 2012-10-23 03:52, David Holmes wrote:
>>>
>>> None of the above AFAICT. Here's the relevant output from bash -x
>>> configure
>>>
>>> ++ case $ac_dashdash$ac_option in
>>> +++ expr x--with-target-bits=32 : 'x-*with-\([^=]*\)'
>>> ++ ac_useropt=target-bits
>>> ++ expr xtarget-bits :
>>> '.*[^-+._abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]'
>>>
>>> ++ ac_useropt_orig=target-bits
>>> +++ printf '%s\n' target-bits
>>> +++ sed 's/[-+.]/_/g'
>>> ++ ac_useropt=target_bits
>>> ++ case $ac_user_opts in
>>> ++ eval 'with_target_bits=$ac_optarg'
>>> +++ with_target_bits=32
>>> ++ for ac_option in '"$@"'
>>> ++ test -n ''
>>> ++ case $ac_option in
>>> ++ ac_optarg=yes
>>> ++ case $ac_dashdash$ac_option in
>>> ++ printf '%s\n' 'configure: WARNING: you should use --build, --host,
>>> --target'
>>> configure: WARNING: you should use --build, --host, --target
>>>
>>> I'm guessing that setting target-bits is triggering some other kind of
>>> argument checking ??
>> There's nothing special with target-bits per se, at this point autoconf
>> is just parsing options and converting them to variables. You can check
>> the shell script in generated-configure.sh, in the one I'm looking right
>> now the "for ac_option" loop starts at line 1073, but this will change
>> as it is regenerated.
>>
>> The only reason I can see that you enter the warning print is that the "
>> case $ac_dashdash$ac_option" falls through into the *) case, which means
>> it didn't match any --with-X or other options. This seem to happen for
>> the option after --with-target-bits, but the log you sent does not show
>> the value of $ac_option for this. If you had included just one more line
>> it would have been:
>> expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
>> which would have given us a hint. :)
>
> Here's a longer section of the output
>
> ++ case $ac_user_opts in
> ++ eval 'with_target_bits=$ac_optarg'
> +++ with_target_bits=32
> ++ for ac_option in '"$@"'
> ++ test -n ''
> ++ case $ac_option in
> ++ ac_optarg=yes
> ++ case $ac_dashdash$ac_option in
> ++ printf '%s\n' 'configure: WARNING: you should use --build, --host,
> --target'
> configure: WARNING: you should use --build, --host, --target
> ++ expr x :
> '.*[^-._abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]'
> ++ : ' '
> ++ for ac_option in '"$@"'
> ++ test -n ''
> ++ case $ac_option in
> ++ ac_optarg=yes
> ++ case $ac_dashdash$ac_option in
> ++ printf '%s\n' 'configure: WARNING: you should use --build, --host,
> --target'
> configure: WARNING: you should use --build, --host, --target
> ++ expr x :
> '.*[^-._abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]'
> ++ : ' '
> ++ for ac_option in '"$@"'
> ++ test -n ''
> ++ case $ac_option in
> ++ ac_optarg=yes
> ++ case $ac_dashdash$ac_option in
> +++ expr x--with-java-path : 'x-*with-\([^=]*\)'
> ++ ac_useropt=java-path
> ++ expr xjava-path :
> '.*[^-+._abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]'
> ++ ac_useropt_orig=java-path
> +++ printf '%s\n' java-path
> +++ sed 's/[-+.]/_/g'
>
> Is it trying to process ' ' (a space as an option ??)
>
>> So I still think there's something weird with your command line.
>
> Yes I think it is an interaction between the script I use to run
> configure and the shell and configure. If I echo the configure command
> and run it directly there is no problem: the shell parses away all the
> whitespace between options. But when run via the script I see:
>
> using configure arguments '--with-jdk-variant=normal
> --with-jvm-variants=client,server --with-target-bits=32 --with-java-path
> --enable-openjdk-only=yes --disable-ccache'.
>
> Note the extra spacing after =32. This arises because my configure
> invocation is actually:
>
> configure $VAR1 $VAR2 $VAR3 ...
>
> where VARn may be empty depending on what target I'm building.
>
> David
>
>>
>>
>>> BTW I also noticed this:
>>>
>>> ac_msg='sources are in
>>> /java/embedded/users/dh198349/build-infra/builds/../common/autoconf,
>>> but `cd
>>> /java/embedded/users/dh198349/build-infra/builds/../common/autoconf'\''
>>> does
>>> not work'
>>>
>>> Though it doesn't seem to cause any problems.
>>
>> You shouldn't go around reading the generated autoconf shell scripts.
>> It's detrimental for your sanity. :-& There's a lot of cruft in there,
>> sometimes I think it's a wonder it all keep from falling apart. But I
>> think the bugs cancel each other out most of the time, so it tend to
>> work pretty well on the whole. :)
>>
>> /Magnus