-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
ROS2 docs still recommend usage of deprecated ament_export_include_directories, _definitions, _libraries, _link_flags #3191
Comments
So as far as I know, we never actually deprecated those old-style CMake functions. I think we could do this, but it hasn't yet been done. However, we still use these functions heavily in the core and in the ecosystem, so deprecating them would be a non-trivial task. That said, I think that the updates in #2915 (along with some of my comments) can reflect the current best practices. That is, we recommend you use CMake targets, but we also still support the old CMake way of doing things. I think the way forward for now is to update that PR, and get that in. |
Right, any way I can help? Another pass over that PR to verify consistency with your statement above? |
Yeah, that's the most we can do and to poke @sloretz with a friendly ping :). |
@clalancette Unless you are strongly opposed, I'd like to deprecate some of these calls on rolling with |
So, first of all, we definitely can't remove these for Jazzy. Our policy is to tick-tock, where in one release we deprecate a feature, and then in the next release we remove it. So the earliest that this could possibly be removed is for K-Turtle. However, I think even that is very ambitious. Just looking around the packages listed in Rolling, I see the following:
I don't think we should carelessly do this deprecation and cause a lot of downstream heartache like this. Instead, I suggest the following:
@sloretz What do you think? Does that sound like a reasonable path? |
Sounds like a reasonable path to me! |
The plan sounds good. |
As part of ament/ament_cmake#365, I noticed all these functions are deprecated, however the docs still recommend users to use them.
Should we start recommending using just native CMake in the migration guide. Also in scope would be the use of ament_target_dependencies.
My proposal is start with recommending to use standard CMake builtin functions whenever possible instead of ament.
I'm happy to submit a PR once the acceptance criteria for this ticket are decided.
The text was updated successfully, but these errors were encountered: