Open ckuethe opened 8 years ago
Would need to fix #313 first.
Where to put the lock file? There's a couple of considerations:
~/.pybombs
.Maybe we need multiple lock files?
I was thinking in the build directory being used by the current pybombs process, since the interference I'm trying to prevent is in source builds.
System package managers usually do their own locking already; if I'm trying to install boost (for example) in two different terminals, one of them will block until the other finishes at which time it will discover that boost is installed and it can do the next thing.
On Sun, May 1, 2016 at 9:51 PM, mbr0wn notifications@github.com wrote:
Where to put the lock file? There's a couple of considerations:
- Most system package managers don't like being called twice. That would point to putting it in ~/.pybombs.
- Two separate prefixes may be worked on in parallel. That would point in putting it into the prefix.
Maybe we need multiple lock files?
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/gnuradio/pybombs/issues/284#issuecomment-216104834
GDB has a 'break' feature; why doesn't it have 'fix' too?
Perhaps it's a case of "don't do that, then" but pybombs should drop a lockfile in the build directory.
eg. Assume that gr-abc and gr-xyz both depend on gnuradio. In on terminal the user says "pybombs install gr-abc". Some time later (but before gnuradio finishes compiling) the user says "pybombs install gr-xyz"; now there will be two instances of pybombs working on building gnuradio, possibly causing a corrupted build.
PyBOMBS already detects when a build directory exists, we should extend that test to check for a lock file containing the process id of the the pybombs instance building in that directory.