[cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Matthew Woehlke]

On 2014-12-18 11:30, Ruslan Baratov via cmake-developers wrote:
> You prefer ".cmake.lock", I prefer "cmake.lock", others prefer
> '.lock'/'.cmake'. For me it doesn't really matter. What matter is the
> *standard* cmake name.

FWIW, I do have a slight preference to using a hidden file :-).

> About "implementation complexity": 
> [...diffs elided...]

There's also the documentation, unit tests...

I don't think there is appreciable maintenance overhead, or I'd feel
more strongly about it. The point was just to consider these things.
(Having written it already also makes the question somewhat moot.)

> I'm the one who will use this feature without timeouts (it's impossible
> to predict some). E.g. cmake instance will run ExternalProject_Add with
> Qt building for > 4 hours, should I set the timeout so my jenkins jobs
> will crash? Or should I print waiting message every second?

I'd print *one* message if the lock has not been obtained "quickly".
Even in the situation you describe, if I were writing the lock, I would
probably wrap it in a helper to print why it's waiting (or else always
print a message before trying to get the lock and once the lock is
held), just so that it's obvious from the logs if a build is stuck
waiting on the lock or stuck for some other reason.

That said... I think you've convinced me that if you need a lock with no
timeout, it should *always* generate status messages, which can more
reasonably be punted to the CMakeLists.txt author.

-- 
Matthew