Lock package directories with lock-files (fixes #957)

[emmabastas]

Synopsis

This pull request fixes #957 using a very simple lock-file approach where the presence of a special .fpm-package-lock indicates that an fpm process is currently working on the package directory and that subsequent fpm processes should wait for the lock-file to be removed.

Checklist

• There are unit-tests for the new module
• There is documentation for the new module
• All tests are passing on Linux+gfort and Windows+Mysys2+gfort, have not tested other setups.

Issues

• I think it would be nice with some sort of integration-testing for this feature, but I haven't added that because I was unsure if it would be appropriate or not (as I understand there's only a unittesting setup right for fpm right now)
• I wrote C functions that pass strings to Fortran and that was very painful for me to implement, and I cannot claim to understand what the precise differences between character(:), allocatable, character(len=1), pointer and type(c_ptr) are..

Implementation notes

The mere presence of .fpm-package-lock is enough for indicate a lock. This means that there are scenarios where a lock-file exists but there is no way of telling if the process that created it is still going or if it crashed. For this reason, if an fpm process sees that a lock-file exists already it prints an informative message to the user instructing them how to manually remove the lock if need be. (this is how git does it)

I went down the path of implementing a more "sophisticated" locking mechanism (see the https://github.com/emmabastas/fpm/tree/concurrent-invocations for my struggles x)) but I ended up concluding that it wouldn't be worth implementing. here's what I wrote in a comment in src/fpm_lock.f90 about that:

A common attempt at improving this situation might be to write the PID +
process start time into the lock-file, that way other processes can verify
that the lock-file wasn't left behind on accident. However this adds quite a
bit of complexity to the code, and it is very difficult / maybe even
impossible to do without race-conditions: There is no atomic way to tell the
OS to:

Open this file for reading with a shared lock in case it exists and
if it doesn't exists then create the file with for writing with an
exclusive lock.

Even if we we're able to do it there is a conceptual flaw: Distributed file
systems. If the package lives on another machine that you're accessing through
something like NFS then you'll end up writing your PID to a file living on
another machine that's not running the process, and so processes on that
machine can't know whether the lock is valid or not.

Now we might turn to actual OS file-locking primitives such as fcntl on UNIX
and LockFile on Windows. This is again a step-up in complexity, and I don't
know about LockFile but fcntl is fraught with problems:
https://chris.improbable.org/2010/12/16/everything-you-never-wanted-to-know-about-file-locking/

My conclusion is that anything more advanced than the current implementation
might just not be worth it, but I'm happy to be proven wrong! :-)