On 04/27/2015 11:48 PM, James Bigler wrote:
The problem is the current detection only barfs (unless I missed something - please correct if I'm wrong). What we need is detection and adaptation. Rather than telling the user, "DON'T DO THAT!" we should be helping the user out by saying, "I know you wanted this to be attached as a MAIN_DEPENDENCY, but that doesn't work, so I'm going to help you out and disable this feature for this file." Then I can specify MAIN_DEPENDENCY and not worry about the collisions that cause problems.
Yes, I prefer the deterministic barfing that diagnoses documented restrictions over elusive build failures.
I am not opposed to your change if your implementation guarantees that the aforementioned build failures don't creep through again.
If I understand correctly you would still output a warning diagnostic when degrading duplicate MAIN_DEPENDENCY?
Not sure I would like that. Most CMake diagnostics generally imply something that the project developer can fix ... which isn't feasible if you make the behavior part of the design in FindCUDA.cmake.
On the other hand the user may himself use MAIN_DEPENDENCY outside the scope of FindCUDA.cmake in which case silent degrading isn't optimal either ... but I guess I could live with that.
Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
