configure WARNINGS

[David Holmes]

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