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 <nilsglad...@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 >
-- 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
