The script is dead, long live autoconf!

Magnus Ihse Bursie magnus.ihse.bursie at
Thu Feb 8 12:51:25 UTC 2018

On 2018-02-07 16:04, Volker Simonis wrote:
> On Wed, Feb 7, 2018 at 2:52 PM, Thomas Stüfe <thomas.stuefe at> wrote:
>> Hi Magnus,
>> short question, is it possible to overwrite the location of autoconf with a
>> configure setting or similar? Similar to "toolchain-path"?
> I doubt because you need autoconf in order to generate the actual
> configure script ( which evaluates the
> arguments.

Exactly. :) That wouldn't make sense.

> We would either need special arguments for the initial configure
> script or pass it through the environment which I think is both not
> worth it if we could just as well put autoconf in the regular path.
What you *can* do is to use the AUTOCONF environment variable. If it's 
too much bother to put it in the environment, you can just prefix your 
calls to configure, or create a script that contains this. I'll repost 
my own "configure" script that I have in ~/bin (which is included in my 
PATH). I created this since it allows me to write "configure --<tab>" to 
get tab completion from bash, but you can also hijack it to setup a 
special AUTOCONF variable.

if [ $(pwd) = $(cd $(dirname $0); pwd) ] ; then
   echo >&2 "Abort: Trying to call configure helper recursively"
   exit 1

bash $PWD/configure "$@"


>> Thanks, Thomas
>> On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie <
>> magnus.ihse.bursie at> wrote:
>>> With JDK-8195689 that has just been pushed to jdk/jdk, the checked-in
>>> runnable script has been removed. Instead, there's a
>>> new build-time dependency on autoconf.
>>> For most users, this should not make any difference. You will still
>>> initiate your configuration by running "bash configure".
>>> If you do not already have autoconf installed, when running configure the
>>> first time after checking out JDK-8195689, this will be detected, and you
>>> will be asked to install autoconf. For most systems, a suggestions on how
>>> to do this is also printed.
>>> If you have made changes to the build system before, you have probably had
>>> a work flow including a custom-built autoconf, running, and
>>> asking someone in Oracle to sponsor your patch for generation of the closed
>>> version of Neither of this will now be needed.
>>> While you can of course keep a custom-built version of autoconf, you might
>>> also delete it. With the new solution, the exact version of autoconf does
>>> not matter. (Note that it will still be needed for backports, though.)
>>> The build documentation has been updated to reflect this change.
>>> /Magnus

More information about the jdk-dev mailing list