automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: choosing compilers in config.ca


From: Warren Young
Subject: Re: choosing compilers in config.ca
Date: Wed, 10 Apr 2019 15:32:51 -0600

On Apr 10, 2019, at 1:59 PM, Matt Pratola <address@hidden> wrote:
> 
> I am trying to write a config.ac script

configure.ac, surely?

And speaking of, I’m pretty sure you’ve send this to the wrong list.  I don’t 
see anything in this question that involves Automake; this is all Autoconf 
stuff.

> that will select between using a
> regular C++ compiler or an MPI C++ compiler.

Are you using hand-rolled code or common third-party ones like these:

    https://www.gnu.org/software/autoconf-archive/ax_prog_cxx_mpi.html
    https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html

If you’re using those two together and they won’t play nice, the authors of 
those macros may be able to help you, and if not, they may accept patches.

And if you’re hand-rolling these tests, why?  You can’t be the only person on 
the planet who needs something this common.

> Later on I check for C++11 support, and then regular build succeeds but the
> MPI build fails.  However, if I change the order of the if statement above,
> then the MPI build succeeds but the regular build fails (or using the mpi++
> compiler even though it should not be set).

You definitely need to check for the compiler first, because that affects every 
other test following it that uses the C++ compiler.  Unless you’re mixing 
compilers that share the same API and ABI, you’ll cause problems otherwise.  
Even mixing two different versions of GCC, as an example, can cause a problem, 
as there have been a few ABI shifts over the years.

If, as you say, nailing the compiler in place first causes later tests to fail, 
you need to get those later tests to work under the environment set up by the 
compiler test, not swap the order, even if it happens to work.

Studying the config.log file is often helpful for this.  The most difficult 
part of debugging an Autoconf script this way is skipping past all the noise in 
that file to see the relevant bit.  I usually search backward for the message 
emitted by ./configure, then keep scrolling up until I get the C/C++ code and 
the resulting compiler/linker messages.

> I am no bash scripting expert, but I am surprised the logic needs to be
> more complicated than this?

Autoconf does require some expertise to use well.  It’s more about achieving 
“possible” in the face of a world of possibilities than achieving “easy.”


reply via email to

[Prev in Thread] Current Thread [Next in Thread]