-
Notifications
You must be signed in to change notification settings - Fork 95
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
Conditionally exclude test dependencies #649
Conversation
In the debian generator, we can decorate the BuildDepends to omit them if the `nocheck` flag is set. For RPMs, there isn't a standard mechanism for skipping tests but we actually created a build flag for skipping tests, so the only work here was to wire that custom flag into the dependency enumeration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's here looks good so far. I can schedule some exploratory testing of the debian behavior with nocheck and propose changes to the debian templates if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the debian generator, we can decorate the BuildDepends to omit them if the
nocheck
flag is set.
The <!nocheck>
in Debian is called a Build-Profile and it's being used in the control file to specify which packages are excluded for testing when the user ask for this kind of "profile". In order to use that profile, we need to set it in DEB_BUILD_OPTIONS
and that variable need to arrive to dpkg-buildpackage. At least, two ways for that I can think of:
- Set
DEB_BUILD_OPTIONS=nocheck
in the rules file via empy templates - Pass
DEB_BUILD_OPTIONS=nocheck
when invoking the build command (not sure if this repo is using debbuild or dpkg-buildpackage calls directly).
I still need to do some testing on the debian side. In particular, I'm not sure if
nocheck
automatically setsENABLE_TESTING=OFF
in the cmake builds.
I don't think that Debian handles the ENABLE_TESTING
variable in anyway and did not find any reference in code to nocheck
build profile particularly. I found some packages implementing that option, is not particularly difficult, just check for nocheck
in DEB_BUILD_OPTIONS
and do the magic in the configure step. See https://sources.debian.org/src/foonathan-memory/0.7.1-4/debian/rules/?hl=43#L43
This was attempted in ros-infrastructure/ros_buildfarm#903 already.
Ah, thanks for the confirmation. I'll add that snippet to this PR then. |
Finally got around to doing some testing on this, and it looks like |
If it helps you, the build profile document provides information on which pieces in the Debian software ecosystem needs to be in place to handle this https://wiki.debian.org/BuildProfileSpec#Document_status Of course that does not mean that our code can work with them but at least we need these set of base packages available to make it work. |
Alright I got this working locally, but I need to resolve these issues:
I'm wading through mailing lists trying to figure out if this is expected behavior or if I'm missing something. |
Good point. The document seems to recommend do it on both:
We probably need to set both of them. To handle |
Okay, my latest commit in this PR when combined with ros-infrastructure/ros_buildfarm#918 and ros-infrastructure/ros_buildfarm#919 is working as expected. I manually tested ament_cmake and catkin packages from ROS 2 and ROS 1, and I didn't see anything strange happening. I'm still a little bit unsure about setting the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to go, with green CI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this change is significant enough that we should bump to the next minor (as bloom is <1.0) and make an announcement of this change (and the related changes in ros_buildfarm) on ROS Discourse.
The changes suggested are just that and completely discretionary.
@[if TestDepends]@\n%if 0%{?with_tests} | ||
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | ||
%endif@\n@[end if]@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just preference and so take it or leave it but I find the embedded newlines less readable than plaintext newlines. This should generate the same result.
@[if TestDepends]@\n%if 0%{?with_tests} | |
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | |
%endif@\n@[end if]@ | |
@[if TestDepends]@ | |
%if 0%{?with_tests} | |
@[for p in TestDepends]@ | |
BuildRequires: @p | |
@[end for]@ | |
%endif | |
@[end if]@ |
@[if TestDepends]@\n%if 0%{?with_tests} | ||
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | ||
%endif@\n@[end if]@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just preference and so take it or leave it but I find the embedded newlines less readable than plaintext newlines. This should generate the same result.
@[if TestDepends]@\n%if 0%{?with_tests} | |
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | |
%endif@\n@[end if]@ | |
@[if TestDepends]@ | |
%if 0%{?with_tests} | |
@[for p in TestDepends]@ | |
BuildRequires: @p@ | |
@[end for]@ | |
%endif | |
@[end if]@ |
@[if TestDepends]@\n%if 0%{?with_tests} | ||
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | ||
%endif@\n@[end if]@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just preference and so take it or leave it but I find the embedded newlines less readable than plaintext newlines. This should generate the same result.
@[if TestDepends]@\n%if 0%{?with_tests} | |
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | |
%endif@\n@[end if]@ | |
@[if TestDepends]@ | |
%if 0%{?with_tests} | |
@[for p in TestDepends]@ | |
BuildRequires: @p | |
@[end for]@ | |
%endif | |
@[end if]@ |
@[if TestDepends]@\n%if 0%{?with_tests} | ||
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | ||
%endif@\n@[end if]@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just preference and so take it or leave it but I find the embedded newlines less readable than plaintext newlines. This should generate the same result.
@[if TestDepends]@\n%if 0%{?with_tests} | |
@[for p in TestDepends]BuildRequires: @p@\n@[end for]@ | |
%endif@\n@[end if]@ | |
@[if TestDepends]@ | |
%if 0%{?with_tests} | |
@[for p in TestDepends]@ | |
BuildRequires: @p | |
@[end for]@ | |
%endif | |
@[end if]@ |
this is implicitly pulled-in through the test depends on rosunit, but fails with ros-infrastructure/bloom#649 which disables test dependencies.
this is implicitly pulled-in through the test depends on rosunit, but fails with ros-infrastructure/bloom#649 which disables test dependencies.
This package is not very critical and it is unclear what it should do at all when testing is disabled. But as the CMakeLists.txt requires these packages during either build, they are NOT just test dependencies. Required to make use of added functions to exclude test depends in builds ros-infrastructure/bloom#649
this is implicitly pulled-in through the test depends on rosunit, but fails with ros-infrastructure/bloom#649 which disables test dependencies.
In the debian generator, we can decorate the BuildDepends to omit them if the
nocheck
flag is set.For RPMs, there isn't a standard mechanism for skipping tests but we actually created a build flag for skipping tests, so the only work here was to wire that custom flag into the dependency enumeration.
I still need to do some testing on the debian side. In particular, I'm not sure if
nocheck
automatically setsENABLE_TESTING=OFF
in the cmake builds. Either way, I think we'll need to update it to setCATKIN_ENABLE_TESTING
appropriately in the catkin template.