FastJet C++14/17 Fixes, 1.0 branch (2019.08.09.)
The clownery around trying to make AnalysisBase/AnalysisTop build successfully on macOS in C++17 mode continues.
As it turns out, our compilation of FastJet(Contrib) was not using even C++14 so far, let alone C++17. This lead to problems when trying to use some FastJet headers in
C++17 mode while building the analysis release. (Clang really doesn't like std::auto_ptr in C++17 mode anymore... This will necessitate other updates in atlas/athena as well.)
The std::auto_ptr problem itself was fixed by the --disable-auto-ptr flag for FastJet's configuration script. But the C++ standard had to be set quit a bit more manually.
I've spent a bit of time trying to figure out how to set up the FastJet build to create a fastjet-config file that would remember that clients should compile their code with the right standard. But apparently that machinery is just broken in FastJet. CONFIG_CXXFLAGS variable inside their skeletons, but I just couldn't find a way to set it to anything.
Finally, since once again I was looking at the LCG_96 build to see how it handled building FastJet with Clang 8, I had yet again to find that it is missing any kind of C++ standard setting. This time around it's not just the Clang 8 build either, the GCC 8 build also didn't use C++17. See:
-
/cvmfs/sft.cern.ch/lcg/releases/LCG_96/fastjet/3.3.2/x86_64-centos7-clang8-opt/logs/fastjet-3.3.2-build.log; -
/cvmfs/sft.cern.ch/lcg/releases/LCG_96/fastjet/3.3.2/x86_64-centos7-gcc8-opt/logs/fastjet-3.3.2-build.log.
So let me once again include @mato on this.
P.S. There's no way of actually telling the FastJetContrib build to use Clang for its build. g++ is hardcoded for the compiler to use...
https://phab.hepforge.org/source/fastjetsvn/browse/contrib/trunk/Makefile.in$13
On macOS this is not an issue per se, since g++ is really just the same as clang++ on it, but on linux this will be a major pain if we (ATLAS) ever want to seriously use clang for our builds...