CPM.cmake
CPM.cmake copied to clipboard
cpm-cmake
Check options
Hey @flagarde, thanks for re-implementing the options check!
Thinking a bit more about the options, I'm not sure if it's a good idea to perform the check in all cases. E.g. often an upstream package would override a downstream version with a newer dependency. In that case the option names and behaviours could have changed, so the old options no longer apply.
Perhaps we should only perform the check if the versions match, or at least offer a way to opt-out?
If I understand how CPM is working now, if the upstream ask for a newer version a warning will be raised and the new version will be used. I think this are two different problems and it would be nice to have the warning for the version and the warning for the options.
If you are not warned you could disable some option necessary downstream without knowing it. Sometimes you don't know exactly what are the need of the used repositories. It could be possible to add an option to disable the check.
Internally CMake use ON so if you want to force only one key maybe you should choose this one
In case you include two time the same repo with the same version : Do you want to keep the previous option or the last one. I suppose you want to keep the last one ?
In cas you have same repo but two version you want new version and the new options right ?
Well with the way CPM.cmake currently works (we immediately add the package after definition), we always use the first version and options added. In case another dependency asks for a newer version that the one currently added, we inform the user it may be necessary to upgrade by outputting a warning. As for options I think we must ask ourselves which scenarios are likely. E.g. if a project adds the same dependency twice, but using different options, I see the following scenarios:
- The version is the same as before: there is a chance that the user was unaware of the other requirement and the options of both should be merged. Other values are to be expected and emitting a warning may be helpful.
- Using a newer version than downstream: the options may have changed in the update and old options could no longer be valid. Not sure what a good default behaviour would be.
- Using an older version than downstream: the user might be unaware of the update and we should warn him about the update and options, which a dependency might rely on.
In all cases we might consider adding an OVERRIDE ON parameter to disable the warning, as the user signals that he knows what he is doing
