file(LOCK <file-name> GUARD ... What do the three GUARDs function, file and process mean exactly?


The long story (below) short, I need to protect a central cmake generated
static code analyzer configuration folder from being overwritten by a second call of cmake.
I currently use if(EXISTS <lock-file.txt>) to terminate a build and otherwise use file(WRITE <lock-file.txt> ) to create the lock file.
After built and SCA analysis phase, the lockfile is removed again.
I assue this approach is not fully safe and therefore wonder if file(LOCK)could be used instead. Would that work? What are the meanings of the three GUARDs exactly. The docu does not describe it.
function: release lock when function is left?
file: release lock when file is left?
process: release lock when process is terminated?
Then non of the three would work directly. But I should be able to use it to protect my if(EXISTS lock) file(WRITE lock code sequence, I guess.

I would appreciate any expertise.



More details:
I generate, using cmake during a normal build process, a static code analyzer (SCA) configuration for a build process into a folder given by a shell env variable SCA_CONFIG_PATH defined in the calling shell. In order to separate the configurations for each cmake call, I wrote a little bash script appending a uuid to the shell defined SCA_CONFIG_PATH=<sca/config/path/ to create separate folder.
If the user forgets to call the uuid script, that central configuration folder created and used by one build would be overwritten by a second started build.
There is even a wrapper tool, calling cmake several times with different setups gathered from other non SCA related config files. I do not have control over that wrapper tool. Also here the configuration path for the SCA tool is passed by env variable SCA_CONFIG_PATH. At least the wrapper tool can be forces using --jobs 1 to do cmake call sequencially. But also that might get forgotten by the user.

Yes, it appears as though there’s no outside-CMake execution scope available. The process-level scope is probably best though. I’m not sure of this history behind the feature as it was merged before we started using GitLab.

Cc: @brad.king

In general as a CMake user also having long-running steps I may want to pick up from later and not repeat (but not a step that CMake is designed to detect), I would also use logic as you have with empty “sca.done” sentinel files, since from the docs file(LOCK isn’t meant for more than a single instance / run.