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

[James Bigler]

Why are we making the restriction more restrictive than it needs to be? We
only need this for multiple targets and not within a single target.

This is how I see it.

1. Using MAIN DEPENDENCY is a useful and desirable feature of FindCUDA.
2. A single input file can be used multiple time to generate different
output files (think .cu to .ptx). This currently works without errors or
warnings.
3. We add this check, and now projects that previously built without
warnings must either:
3.a. Disable useful feature of MAIN DEPENDENCY
3.b. Turn policy off - the user may not even realize why this was triggered
in the first place because this code was generated by FindCUDA.
3.c. User will need to go through and manually filter out which files can't
have MAIN DEPENDENCY.
3.d FindCUDA disables MAIN DEPENDENCY by default to the detriment of all
users.

Ideally what should happen is:
1. MAIN DEPENDENCY issues cross targets should automatically be downgraded
to DEPENDENCY with a warning.
2. MAIN DEPENDENCY within a target works as before.

This will have the greatest backward compatibility and be of the most use
to users.


I'm also curious why specifying MAIN DEPENDENCY in make file generators has
any special effect since according the documentation there be no functional
difference. It seems like this is more a bug in how MAIN DEPENDENCY is
being handled. Using warnings and errors to correct this seems a bit like
the wrong solution.
On Tue, Apr 28, 2015 at 1:10 AM Nils Gladitz <nilsgladitz at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150428/ba71cf83/attachment.html>