RFR: AARCH64: Top-level JDK changes

[Christian Thalinger]

> On Nov 19, 2014, at 12:56 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> 
> On 2014-11-18 19:09, Christian Thalinger wrote:
>>> On Nov 18, 2014, at 7:36 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>> 
>>> On 2014-11-18 01:59, Christian Thalinger wrote:
>>>>> On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>>>> 
>>>>> On 2014-11-14 21:44, Dean Long wrote:
>>>>>>> The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are allowed to edit it, though.
>>>>>> What if we require Autoconf to be installed on the host?  Does that solve any problems?
>>>>> No, unfortunately not.
>>>> Why not?
>>> Autoconf picks up these files automatically from the build-aux directory. That's also the reason we need to rename the original files and provide wrappers with the same name, since we can't even redirect that functionality to a file with another name.
>> So do I understand you correctly that the files we need are automatically copied into the workspace but since we want to use our own, old versions we renamed them and use these instead?
> No, I will try to clarify.
> 
> Autoconf is a tool that takes one (or more) input files (written in m4 macro language) and generates a shell script, often named "configure". This shell script is what you would typically run to configure your project. Autoconf defines an API of m4 macros specifically for configure scripts which is basically what makes it useful. Most of these macros are expanded into the generated configure script.
> 
> However, for reasons unknown to us, some of the more complex functionality has been split out into separate shell script "library" files. These library files, often referred to as "build-aux" are supposed to be distributed with the project source code, along with the generated configure script. We distribute them in common/autoconf/build-aux. These files can be found in the source distribution of autoconf or by downloading from the official scm repo for them. They are not part of the binary distribution of autoconf on my Ubuntu system at least.

Well, that’s because config.guess and config.sub are part of automake:

http://git.savannah.gnu.org/gitweb/?p=automake.git;a=tree;f=lib;hb=HEAD <http://git.savannah.gnu.org/gitweb/?p=automake.git;a=tree;f=lib;hb=HEAD>

and installed e.g. in this directory on Solaris:

$ ls /usr/share/automake-1.10/
acinstall*  ansi2knr.1  Automake/  config-ml.in   config.sub*  depcomp*     INSTALL      mdate-sh*  mkinstalldirs*  symlink-tree*  ylwrap*
am/         ansi2knr.c  compile*   config.guess*  COPYING      elisp-comp*  install-sh*  missing*   py-compile*     texinfo.tex

$ automake --add-missing

makes a copy of these files, if necessary:

configure.ac:3: the top level
configure.ac:3: installing `./config.sub'
configure.ac:3: installing `./config.guess'

$ ls -l config.*
lrwxrwxrwx 1 cthaling staff 37 2014-11-19 16:26 config.guess -> /usr/share/automake-1.10/config.guess*
lrwxrwxrwx 1 cthaling staff 35 2014-11-19 16:26 config.sub -> /usr/share/automake-1.10/config.sub*

> For this reason, it wouldn't help requiring autoconf to be installed as that wouldn't provide the files.
> 
> For non GPL projects to be able to distribute the files in build-aux, they come with a special exception to GPL, which basically allows them to be freely distributed as long as they are part of a configure script. This exception does not seem to give any exception for deriving work from them.
> 
> /Erik