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

Uniform CMake dependency handling to the YARP/ICUB style #322

Closed
traversaro opened this issue Jun 15, 2017 · 1 comment
Closed

Uniform CMake dependency handling to the YARP/ICUB style #322

traversaro opened this issue Jun 15, 2017 · 1 comment

Comments

@traversaro
Copy link
Member

Currently, all dependencies in iDynTree are searched or not based on the IDYNTREE_USES_<dep> CMake option. This is convenient for its simplicity, but quite cumbersome because a user needs to select explicitly the dependency that he wants to enable. This do not apply to superbuild, but it applies to people building the library standalone.

I am against always enabling the dependency automatically if they are found, because it prevents the user to manually select the dependency that he wants to build, and it prevents to have a clear and nice error if a dependency requested by the user is not satisfied.

I think a good trade-off is the one used in YARP/ICUB, in which the initial value for the IDYNTREE_USES_<dep> option is set to TRUE if <dep> is found on the system, and FALSE otherwise. Then the user is free to select/deselect the option that he/she prefers.

@traversaro traversaro changed the title Uniform dependency handling to the YARP/ICUB style Uniform CMake dependency handling to the YARP/ICUB style Jun 15, 2017
traversaro added a commit that referenced this issue Jun 15, 2017
traversaro added a commit that referenced this issue Jun 15, 2017
traversaro added a commit that referenced this issue Jun 15, 2017
@traversaro
Copy link
Member Author

Done in #323 .

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

1 participant