RFR: AARCH64: 8064357: Top-level JDK changes

[Dean Long]

I was thinking 'hg mv config.sub autoconf-config.sub' and then
'hg add config.sub' so it doesn't look like we are modifying the 
upstream version
of config.sub, but maybe it's not a big deal?

dl

On 11/21/2014 12:03 PM, Vladimir Kozlov wrote:
> The history is preserved since patch is applied above config.sub.
> I did 'hg copy config.sub autoconf-config.sub' and then applied the 
> patch.
>
> And there are only 2 changesets in config.sub:
>
> changeset:   574:b66c81dfa291
> user:        ohair
> date:        Mon Jan 14 16:38:25 2013 -0800
> summary:     8005284: build-infra: nonstandard copyright headers under 
> common/autoconf/build-aux
>
> changeset:   423:e1830598f0b7
> parent:      417:42f275168fa5
> user:        ohair
> date:        Tue Apr 10 08:18:28 2012 -0700
> summary:     7074397: Build infrastructure changes (makefile re-write)
>
> Thanks,
> Vladimir
>
>
> On 11/21/14 11:31 AM, Dean Long wrote:
>> One minor comment:  do we want to preserve the history in the new
>> config.sub,
>> or check it in as a new file?
>>
>> dl
>>
>> On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote:
>>>
>>> On 2014-11-21 18:02, Andrew Haley wrote:
>>>> On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote:
>>>>> 1) Comment in config.sub identifies it as config.guess.
>>>>>
>>>>> 2) As as understand it, your first attempt is to just dispatch 
>>>>> through
>>>>> to autoconf-config.sub if there is no aarch64 arguments. Good! 
>>>>> However,
>>>>> the code could be made clearer: The dot is small and some comment
>>>>> clarifying that we will exit after this line might be helpful to the
>>>>> reader. Also, you're using a $sub_args which is not defined. This 
>>>>> will
>>>>> not break, but it makes the reader confused. (I suspect copy/paste
>>>>> glitch.)
>>>>>
>>>>> 3) The webrev indicates that the original config.sub was renamed to
>>>>> config.sub.orig, instead of autoconf-config.sub. But since that is 
>>>>> how
>>>>> it is called in the new config.sub wrapper, the patch is unlikely to
>>>>> work. When you test this, make sure you have no lingering files in 
>>>>> your
>>>>> workspace that can mess up the results. (e.g. no "?" files in hg
>>>>> status).
>>>> http://cr.openjdk.java.net/~aph/aarch64-8064357-5/
>>>
>>> Looks good to me.
>>>
>>> Thanks for working through all these iterations!
>>>
>>> /Magnus
>>