Skip to content
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

[feature] CMake add_executable imported #17015

Closed
1 task done
vasama opened this issue Sep 18, 2024 · 2 comments
Closed
1 task done

[feature] CMake add_executable imported #17015

vasama opened this issue Sep 18, 2024 · 2 comments
Assignees

Comments

@vasama
Copy link

vasama commented Sep 18, 2024

What is your suggestion?

CMakeDeps creates IMPORTED library targets, but for application packages or packages containing applications, it does not create IMPORTED executable targets. This is unfortunate, because while in the CMake project which builds the executable, the target name can be used in a custom target: add_custom_target(my_target my::app) and the name of the application binary cannot. When the package is found via the script generated by CMakeDeps, this is reversed; the application binary is in path, but no target is created. This is particularly problematic for CMake scripts that make use of the application and should be usable in both contexts.

I would like to have some way to specify the name of a CMake IMPORTED executable target for a particular binary in a Conan package.

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded memsharded self-assigned this Sep 18, 2024
@memsharded
Copy link
Member

Hi @vasama

Thanks for your suggestion.

This would be a duplicate request, we have already very recently started an effort to provide this, see this PR: #16964

The original request would be #7240, I think this might be closed as duplicated and progress can be followed up there.

This is particularly problematic for CMake scripts that make use of the application and should be usable in both contexts.

Note however that this will probably require some special treatment, as if targets are generated for the "host" context, they will fail to execute in many scenarios, like cross-building, so the targets from the "build" context should generally be the ones to be prioritized.

@vasama
Copy link
Author

vasama commented Sep 18, 2024

Closed as duplicate.

@vasama vasama closed this as completed Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants