Thank you for the backports!

I'm hesitant to accept this backport. While it's uncommon, I've come across people hard-coding include paths to use their non-CMake build system. This change would break those kinds of builds.

That perspective was certainly overlooked for me, thank you!
The decision on whether to change the install target and cut off users that is like you mentioned should be made by package developers using ament_cmake, not by us ament_cmake developers.

On the other hand, at present, the only way to apply this change to anything other than rolling is to use a patched fork to build ament_cmake from source.

However, since I want more people to use this patch and put an end to the include path pollution, I came up with an alternative solution.

I propose to add an argument to the ament_auto_package function to switch the install target (defaulting to legacy behavior to ensure backwards compatibility).
With this proposal, the install target switch would not be applied automatically, and users would have the choice. What do you think?

I propose to add an argument to the ament_auto_package function to switch the install target (defaulting to legacy behavior to ensure backwards compatibility).
With this proposal, the install target switch would not be applied automatically, and users would have the choice. What do you think?

I think that's a great idea!

Thank you for your advice.
I'll implement the proposal and close this directly backporting pull-request.

@sloretz I implemented the idea on #577. Could you review it?