CMake replacing Autotools?

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Thu Mar 18 13:12:08 UTC 2021


On 2021-03-18 00:21, Christoph Grüninger wrote:
> Dear Java devs,
>
> what do you think about the idea to replace Autotools by CMake? Is there
> any chance anybody would be interested?
> Would it be worth to write a feature request? Or even a JEP?
>
> If somebody is interested I could elaborate more about why I think CMake
> has advantages over Autotools.

Did you have any specific complaints about the build system, or is this 
just some general CMake cheerleading? In any way, I don't see how 
replacing the current build framework with CMake would bring any benefit 
that even remotely come close to the cost of doing that. But if you want 
to elaborate on your thinking, by all means, go ahead!

How much have you actually looked at the build source code? We are not 
really what I'd describe as an "autotools" project. It is true that we 
still use autoconf to create our final configure script, but we have 
steadily moved away from most of the provided AC_* macros, since they 
have proven inadequate for our needs. And we have never even considered 
using automake. In fact, a more proper description would be to say that 
our configure script consists of a bash script generated using m4, with 
a few remaining support macros incorporated from the autoconf libraries.

At various times, I have dreamed of replacing the configure script with 
something that is more modern and easy to maintain than this bash/m4 
mix. We have a very well-defined API for the configure script: the user 
calls "bash configure" in the root directory of the project, with a set 
of --options, and as a result we create a spec.gmk file that defines the 
configuration. This could easily be replicated in another system. But if 
I were to rewrite this from scratch, I'd rather write the whole 
configure logic in Java (apart from some thin shell script logic needed 
to find the boot jdk), rather than trying to shoehorn in our build model 
in CMake.

/Magnus



More information about the build-dev mailing list