[cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY

[Nils Gladitz]

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