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 thi
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 p
On 28.04.2015 16:50, James Bigler wrote:
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.
I wasn't aware of that use case and I misdiagnosed the underlying issue
as well.
The issue isn't having mul
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
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 yo
>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 tar
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 thi
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 l
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 t
10 matches
Mail list logo