On 05/12/2015 07:23 AM, James Bigler wrote:
OK, thanks.
I still think that if there is a difference in behavior for Makefile
generators between MAIN_DEPENDENCY and DEPENDENCY there is a bug in
CMake. Perhaps there needs to be bug filed for that. Here's the
documentation:
In makefile terms
OK, thanks.
I still think that if there is a difference in behavior for Makefile
generators between MAIN_DEPENDENCY and DEPENDENCY there is a bug in CMake.
Perhaps there needs to be bug filed for that. Here's the documentation:
In makefile terms this creates a new target in the following form::
On 29.04.2015 09:11, Nils Gladitz wrote:
The policy will likely have to be removed or replaced.
I reverted the MAIN_DEPENDENCY specific CMP0057 commits and replaced the
policy with an unrelated one that is part of my if-IN_LIST topic to
fill the gap.
This leaves the original issues that
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
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
From what I understand the only time this really became a problem was when
there were multiple instances of MAIN_DEPENENCY across multiple targets.
If done within a single target CMake did the right thing and only attached
the first build rule.
The issue really seems to be related to multiple
On 04/24/2015 05:43 PM, James Bigler wrote:
This new policy breaks a long standing feature of FindCUDA.
Basically I could add the MAIN_DEPENDENCY to all CUDA files built.
If the same CUDA file was used in multiple custom commands it would
attach the build rule to the first command, and leave
On 04/27/2015 03:31 PM, Brad King wrote:
The policy was added to diagnose some previously-broken cases earlier.
We technically never supported duplicate MAIN_DEPENDENCY specification
but did not diagnose it. Instead it could produce bad builds in some
cases IIRC.
Nils, do you remember where
This new policy breaks a long standing feature of FindCUDA.
Basically I could add the MAIN_DEPENDENCY to all CUDA files built. If the
same CUDA file was used in multiple custom commands it would attach the
build rule to the first command, and leave the remaining ones as phantom
.rule files in
