version.h: automatically bump patch number for devel builds

[rhaschke]

Follow up on #2793: Automatically recognize a devel build by comparing package.xml's version with available git tags. If they don't match, assume a devel version, increase patch number and append -devel.

[codecov[bot]]

Codecov Report

Base: 62.08% // Head: 62.09% // Increases project coverage by +0.01% :tada:

Coverage data is based on head (2a1a7ce) compared to base (1245f15). Patch has no changes to coverable lines.

:exclamation: Current head 2a1a7ce differs from pull request most recent head 52d5dcd. Consider uploading reports for the commit 52d5dcd to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3211      +/-   ##
==========================================
+ Coverage   62.08%   62.09%   +0.01%     
==========================================
  Files         376      376              
  Lines       33179    33179              
==========================================
+ Hits        20595    20598       +3     
+ Misses      12584    12581       -3     

Impacted Files	Coverage Δ
moveit_core/robot_state/src/robot_state.cpp	52.09% <0.00%> (+0.09%)	:arrow_up:
...g_scene_interface/src/planning_scene_interface.cpp	52.20% <0.00%> (+1.10%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[AndyZe]

I don't feel entirely qualified to review this. Is there a way to see that it worked? Is there any downside if it does not work as intended?

[rhaschke]

Is there a way to see that it worked? Is there any downside if it does not work as intended?

Just run cmake on different commits. It will print the corresponding version number.

[AndyZe]

OK, I'm testing like this:

cd ../moveit/moveit_core cmake . | grep "Building MoveIt" --> no output Change the version tag in ./package.xml to something new: <version>1.1.27</version> cmake . | grep "Building MoveIt" --> still no output

Sorry, I must be doing something wrong.

[rhaschke]

The output message is part of the make log (not cmake):

> grep -r "Building MoveIt" logs
logs/moveit_core/build.make.log:--  *** Building MoveIt 1.1.10-devel ***

or catkin b --no-deps moveit_core -v | grep "Building MoveIt"

The devel prefix (and auto-increment of patch number) will only be omitted if the current git commit will have the same version tag as stated in package.xml. Thus changing the version in package.xml will not illustrate the behavior. You need to declare a version tag for your git commit.

[AndyZe]

Thanks Robert. I can at least see some output now. I'm not sure it's the intended output:

• This branch without any changes: *** Building MoveIt 1.1.10-devel ***
• Add a couple test commits but no tags: *** Building MoveIt 1.1.10-devel ***
• Add a test commit with tag 1.1.11: *** Building MoveIt 1.1.10-devel ***
• Add a test commit with tag 1.1.11 and bump version in package.xml to 1.1.11: *** Building MoveIt 1.1.11 *** (Finally a change!)

[AndyZe]

Actually I think that^ output makes sense. Please confirm, then I'm good to merge.

[rhaschke]

Yes, that's the intended behavior. The key question to other maintainers was whether this behavior is considered reasonable, particularly @simonschmeisser and @v4hn.

[rhaschke]

Note that the bump of the version number is only visible in version.h, i.e. to source code using that include. The library SO versions are stuck to the "old" version number given in package.xml.

[rhaschke]

@tylerjw, I'm also very curious about your opinion on this PR.

[simonschmeisser]

Maybe it's a red herring but I see a lot more rebuilds of dependent packages in my catkin workspace since this change (I assume, haven't verified). It seems the version.h is touched on every catkin build now? Can we avoid this somehow?

[rhaschke]

You are right: version.h is regenerated on every catkin build. However, cmake's configure_file should take care of not changing the file's timestamp if the content didn't change: https://stackoverflow.com/questions/71776252/cmake-configure-file-does-not-touch-if-the-file-is-the-same

Could you please collect more evidence that this is not the case?