-
-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to specify a different build number for a single package and remove full_rebuild and skip_all_deps options #67
Allow to specify a different build number for a single package and remove full_rebuild and skip_all_deps options #67
Conversation
This commit allow to specify a different build number for a single package, to allow to perform a fix to a build of a single package, without the need to do a full rebuild. This is an advanced option, so special care is needed: * A rebuild is only possible if it does not change the version or in any other way the ABI of the package. * On the following full rebuild, it is important to make sure that the build number select is higher then any custom build number used for single packages.
eaa5524
to
cc79494
Compare
I really like this change – it simplifies things a lot! Should we use this opportunity to do some more cleanup?
|
I done the first point, I look on the other points. For the other two points, I should completly remove the |
For Line 116 in aa102b2
|
Yes, I think we should completely remove |
Good point! The migrate tool should bump the build number of the affected packages. |
I'm happy to merge as soon as you are; I've done a quick update to #64 to write into |
Done in debb33e . The PR is ready for merge. |
This commit allow to specify a different build number for a single package, to allow to perform a fix to a build of a single package, without the need to do a full rebuild.
This is an advanced option, so special care is needed:
To permit to do this, I did the following changes:
pkg_additional_info.yaml
file meant to specify additional package-specific options. I introduced this file here, but it will also be useful for the work I plan to do to easily de-vendor packages (together with ament_vendor: Add AMENT_VENDOR_NEVER_VENDOR ament/ament_cmake#552)selected_bn
variable that I did not fully get, that was using a different build number depending on the build number of the packages present in the target upload channel. I was a bit afraid to simply remove it, but I added theuse_explicit_build_number: True
option to bypass this logic, the idea is that we adduse_explicit_build_number: True
to all the vinca config files, and then if everything works fine, we can simply drop that logic.The motivation for this came out as in RoboStack/ros-humble#242 we accidentally did a build of
lanelet2-io
with a wrong pugixml pinning, and in general it would be great to be able to do fixes that preserve the ABI without doing a full rebuild.