Setting configure options inside the configure script/Autotools with Boost installed in an unusual location (EPEL alternative boost installs)

Question

I am currently working on an Autotools-based build system running on RHEL7. The system version of Boost is quite old (1.53), however there is a newer one provided through EPEL (1.69). This newer version is needed for some of the libraries that were more recently added to Boost, such as Boost::Log.

Unfortunately, it does not work transparently with either of the standard Autotools Boost bootstrapping scripts, boost.m4 or ax_boost_*.m4, due to it installing in a slightly unusual location (/usr/include/boost169 and /usr/lib64/boost169). It can be made to work with ax_boost_*.m4 by setting --with-boost=[include dir] and --with-boost-libdir=[lib dir] ; however, this is a build system for a large group and I'm not wanting everyone to have to manually set this every time, when it's always going to be the same across all of our builds.

So I am looking for two things. First, Is there a good way to optionally set the configure options inside configure.ac? It's pretty easy to check if the directories are there, and I could set --with-boost and --with-boost-libdir before calling AX_BOOST_BASE if the user hasn't already set them. This would let me make my own boost M4 file that checks if a newer version of Boost is installed to an EPEL location and if so, set those options and use it.

Second... is this even the right way to go about this, or is there a cleaner way to set up the entire process?

Answer 1

First, Is there a good way to optionally set the configure options inside configure.ac?

I take you to be asking whether you can modify your configure.ac to artificially inject program arguments that will be recognized and handled as if they had been specified on the command line. To the best of my knowledge, no, there is no way to do that without hacking Autoconf itself.

It's pretty easy to check if the directories are there, and I could set --with-boost and --with-boost-libdir before calling AX_BOOST_BASE if the user hasn't already set them. This would let me make my own boost M4 file that checks if a newer version of Boost is installed to an EPEL location and if so, set those options and use it.

It would be viable to modify AX_BOOST_BASE to alter the behavior when the --with-boost* options are not specified, but it seems like you may be thinking too small. If you're configuring a package that requires a certain minimum version of Boost, then you should be expressing that to AX_BOOST_BASE via its first (optional) argument. That's probably not enough by itself to serve your need, but it is enough that AX_BOOST_BASE should reject too-old versions. In that case, it looks like it falls back to checking other locations, and there is where you can teach it to check locations of the form you need to handle.

So

1. Make sure your configure.ac specifies an appropriate minimum Boost version
2. Include a smarter AX_BOOST_BASE that knows how to check the library locations you want to use

Second... is this even the right way to go about this, or is there a cleaner way to set up the entire process?

The variation I've suggested seems reasonable to me and pretty clean, but it will require a bit of work to implement. How much depends on how comfortable you are with shell and Autoconf programming. You might consider contributing the resulting modified macro back to the Autoconf archive (and starting with the latest version from there), as that would reduce the likelihood of having to do this again.

Another, easier alternative would be to provide a wrapper script that runs configure with the wanted options, and instruct the team to use that instead of running configure directly. In this case, it would still be useful and appropriate to make sure that the minimum acceptable Boost version is passed to AX_BOOST_BASE .