Load library version

[GiovanniBussi]

Description

The plumed mklib script in v2.10 works as a makefile, so that if a .so is already present it is not recompiled. This is necessary for thread safety. This however causes a problem in the plumed nest where the .so file produced by v2.9 is not regenerated when using master. One possible solution is to encode the version name in the .so file.

With this PR, when using

LOAD FILE=file.cpp

A .so file will be generated with name file.2.10-dev.so.

Notice that the change is apparent only when using LOAD, and not when using plumed mklib directly. In other words:

plumed mklib file.cpp

will still generate a file named file.so.

I did it in this way, which is completely transparent to users. Indeed, the .so file created by LOAD is a temporary that is never explicitly mentioned by the user. However, it would also be possible to encode the version directly in every use of plumed mklib, which I think is what python does when compiling extensions. This would however create problems if someone uses scripts such as:

plumed mklib file.cpp
cat << EOF > plumed.dat
LOAD FILE=file.so # wrong name here!
EOF 

Target release

I would like my code to appear in release v2.10

[GiovanniBussi]

In the latest version (dfe0657) I changed the behavior of plumed mklib so that the makefile-way of working should be explicitly enabled with a -n flag (by analogy with mv -n). In this way:

• plumed mklib file.cpp works as it was working on v2.9, that is it overwrites file.so. This is safer, when there are multiple versions of plumed installed on a system, since it is sufficient to call plumed mklib without the need to previously remove the file.so file
• LOAD FILE=file.cpp calls plumed mklib -n -o file.2.10-dev.so file.cpp, which does not overwrite existing libraries (-n), so as to work in multithread contexts, but add a version suffix.