Add a configuration variable to designate that cmake is being run in parallel with other instances

[jbohren]

There are some files which catkin modifies which have the potential to introduce race conditions if multiple cmake instances are building catkin packages with a merged develspace as they do in catkin build. This was originally described in #670.

In this case, extra care can be taken to guarantee that these race conditions cannot occur. The files affected are:

• The develspace marker file, .catkin, which contains a ;-delimited list of sourcespace paths. Create thread-safe storage of source-space paths #674

[dirk-thomas]

Please consider to provide a pull request for this.

[dirk-thomas]

Since the initial comment only mentions the .catkin file is this still relevant after #671 has been merged?

[dirk-thomas]

I will close this due to lack of response for now. Please feel free to comment here and the ticket can be reopened if necessary.

[cmansley]

FYI this is still a serious issue for our project. It is actually making our Jenkins instance fail regularly because of corrupted ROS_PACKAGE_PATH, which some packages depend on.

[dirk-thomas]

I will reopen the ticket then. But somebody needs to actively work on this if it is a relevant problem. @jbohren?

[jbohren]

In catkin/catkin_tools#196, the tool creates the .catkin file instead of the Catkin CMake code, so you don't miss any packages.

[cmansley]

Awesome work over there. In catkin/catkin_tools#196, @wjwwood mentions that it would be great if we could split stuff up to review separately. How hard would it be to pop out just the creation and locking for the .catkin file to close this series of issues and pull requests related to this race condition?

Because using your awesome script from here, I am getting a failure rate of like 48% with 30 trials. So, this seems to be a high priority bug.

I can't imagine it is my setup as your script creates packages and builds them.

[jbohren]

@wjwwood mentions that it would be great if we could split stuff up to review separately. How hard would it be to pop out just the creation and locking for the .catkin file to close this series of issues and pull requests related to this race condition?

It would be pretty hard to separate that out.

Because using your awesome script from here, I am getting a failure rate of like 48% with 30 trials. So, this seems to be a high priority bug.

Yeah, it was basically happening to me every time I rebuilt a workspace.

[cmansley]

So, the mystery deepens. @jbohren you had used all file(APPEND ...) in all.cmake in your original pull request #672. Later you modified it to contain a "write" to initially create the file here f23396d. Then, later you modified it again to make sure we don't have a semicolon here 46da0c4. If I leave the way it currently exists, I get something like 50% race condition with the race.zsh script. If I modify everything to be append in that section, I get something like 5%. I will submit a PR to change everything in that section to APPENDs instead of WRITEs. Unless, there is a very specific reason for those commands to be WRITEs instead of APPENDs.

[cmansley]

See #752.

Again, this does not solve our problems, but it reduces the exposure on my machine by an order of magnitude. I am really looking forward to a real solution from catkin/catkin_tools#196

[dirk-thomas]

I will close this issue for now since it is unlikely that anyony is working on this in the future and it is unclear how this could be addressed in catkin itself.

Imo the build tool should avoid performing tasks in parallel which access the same files, e.g. by passing CATKIN_BUILD_BINARY_PACKAGE and generating these files itself.