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

IMPORTED_TARGETS Property #118

Open
ryanmrichard opened this issue Sep 13, 2023 · 4 comments
Open

IMPORTED_TARGETS Property #118

ryanmrichard opened this issue Sep 13, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@ryanmrichard
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
find_or_build_dependency requires specifying the targets CMaize will find. Apparently in CMake 3.21 there is a new directory property IMPORTED_TARGETS which can be used to get the list of targets which come from importing a dependency. Can this be used to automate finding the targets?

Describe the solution you'd like
To not have to specify the targets.

@ryanmrichard ryanmrichard added the enhancement New feature or request label Sep 13, 2023
@zachcran
Copy link
Contributor

Potentially. Brainstorming here, I'm envisioning storing the IMPORTED_TARGETS list before the find_package call, then again after. If the list changed, it was imported successfully and the newly added target name(s) came from the new package.

At a minimum, we could use it to check if the target the user specified was actually imported, raising more informative errors/warnings and potentially suggesting a "similar" target (contains the given target name, not a more complex string similarity algorithm).

@ryanmrichard
Copy link
Collaborator Author

I was thinking something along those lines too. Where this may backfire is TiledArray for example. TiledArray contributes a lot of targets to the namespace besides just the TA target (for example you pick up MADNESS and Umpire targets as well). That said, since say TensorWrapper transitively depends on all of those targets through TA anyways it's not clear to me that explicitly making TensorWrapper depend on all of them would actually break anything.

@zachcran
Copy link
Contributor

zachcran commented Sep 15, 2023

I don't think TensorWrapper explicitly depending on MADNESS and Umpire would break anything as long as TensorWrapper and TA are both compatible with the same MADNESS and Umpire versions (which I think can safely be assumed). I'm not sure how we could reliably choose the target(s) associated directly with TA vs its dependencies while still reducing the size of the CMakeLists.txt file right now.

@ryanmrichard
Copy link
Collaborator Author

I'm not sure how we could reliably choose the target(s) associated directly with TA vs its dependencies while still reducing the size of the CMakeLists.txt file right now.

I don't think we can. If we're going to try this I think we should still allow the user to specify the targets if they want, and just have the default be auto-discovery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants