configure WARNINGS

[Magnus Ihse Bursie]

So, anyway, it's harmless. But I can understand that it's a bit annoying. 

Are your script calling the top-level configure or common/autoconf/configure? If it is the former, try going directly on the latter to skip yet another layer of shell interaction. If it is the latter, try the former to see if the extra invocation can help you strip the space away. :-)

/Magnus

25 okt 2012 kl. 06:07 skrev David Holmes <david.holmes at oracle.com>:

> > 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