Use TemporaryDirectory for g++ version detection

[GabrielMajeri]

Context: When MadAnalysis5 is installed in a common (shared) directory so that multiple people can use it, the installation directory might not be writable by the current user. In this case, detecting the version of the C++ standard supported by the compiler will invariably fail, since MA cannot create the cxxtest.cc file in the installation directory.

Description of the Change: This changes the code to use a temporary directory for building the test program.

Benefits: MadAnalysis5 can now be used as a shared install.

Possible Drawbacks: None I could think of.

I haven't updated the changelog because I couldn't find the changelog-dev.md file.

[jackaraz]

Hi @GabrielMajeri, thanks for the PR. I have a question about your implementation. Each and every feature of Ma5 is based on reading and writing one or multiple files at every stage of the analysis, and the file you mentioned is only one of them. If the user does not have write permissions, Ma5 will fail at various stages. Not sure if your improvement will fix the issue; granting the users the correct permissions might be easier.

[GabrielMajeri]

Each and every feature of Ma5 is based on reading and writing one or multiple files at every stage of the analysis, and the file you mentioned is only one of them.

I have encountered this issue while trying to use MA5 through MadGraph. It would refuse to generate the MA commands card, throwing an exception when checking the configuration (raise MA5Configuration('Issue with the configuration')).

After some debugging, I've traced the issue back to the detect_gpp module, and realized that it was failing to create the C++ source file for the test program.

With this change, MG is able to import the MA interpreter without issues, correctly generates the command file and then runs it. I am again able to see MA-generated analyses in the MG output directory.

Indeed, trying to run MA directly might still fail (for example, if it says System configuration has changed since the last use. Need to rebuild the library., it will try to rebuild the shared libraries which are stored in the common directory, and fail, since it lacks permissions to write to it). But at least in this scenario which I care about, it seems to fix the problem.

granting the users the correct permissions might be easier.

What are the "correct permissions"? The whole point of our shared install is to make sure that only a system administrator will handle installing/updating the tools. The other people in our group who aren't so technical do not get write permissions to the directory, precisely to avoid them accidentally breaking anything.

Most of the tools we use are compatible with this installation approach (read-only install dir, writable user dir).