RFR: AARCH64: Top-level JDK changes

Erik Joelsson erik.joelsson at oracle.com
Wed Nov 19 08:56:09 UTC 2014


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


More information about the jdk9-dev mailing list