Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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 this creates a new target in the following form:: OUTPUT: MAIN_DEPENDENCY DEPENDS COMMAND For a makefile, there shouldn't be a difference between the dependency coming in on MAIN_DEPENDENCY or DEPENDENCY. CMake is doing something else with that property. I would prefer that too but the add_custom_command() implementation which handles MAIN_DEPENDENCY and DEPENDENCY and attaches commands to source files is common to all generators. Treating MAIN_DEPENDENCY and DEPENDENCY the same for Makefiles in this case would break existing projects (when using the Makefile generators) when they list the source file named by MAIN_DEPENDENCY but not the source file named by OUTPUT since then the custom command would not get emitted at all. 2. I'm curious why this causes a problem. It seems to me that dummy.cpp should be present by the time the add_custom_command is even run, Yes, it is. so why would it care whether it was created by CMake or anything else? That isn't the issue. The test case failure depends on the presence of the custom command but the custom command is not involved in creation of dummy.cpp; it only uses it as input. Due to MAIN_DEPENDENCY the custom command is attached to dummy.cpp. I think the issue is due to cmake trying to attach the command used to compile dummy.cpp itself as a custom command as well. [1] Nils [1] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;h=88c88cd133a753fc319a785e116fdb8e6d5fd94a;hb=HEAD#l580 -- 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
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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::
OUTPUT: MAIN_DEPENDENCY DEPENDS
COMMAND
For a makefile, there shouldn't be a difference between the dependency
coming in on MAIN_DEPENDENCY or DEPENDENCY. CMake is doing something else
with that property.
2. I'm curious why this causes a problem. It seems to me that dummy.cpp
should be present by the time the add_custom_command is even run, so why
would it care whether it was created by CMake or anything else?
James
On Thu, Apr 30, 2015 at 9:42 AM, Nils Gladitz nilsglad...@gmail.com wrote:
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 prompted the creation of CMP0057 open
for now.
Two related but distinct issues are triggered by the following test cases
with the Makefile generator:
1) The following causes the given custom command to be emitted for both
the foo and bar target which can lead to parallel build errors:
cmake_minimum_required(VERSION 3.2)
file(WRITE test.in)
file(WRITE dummy.cpp int main() {})
add_custom_command(
OUTPUT test.out
COMMAND ${CMAKE_COMMAND} -E echo Hello World
MAIN_DEPENDENCY test.in
)
add_executable(foo dummy.cpp test.in)
add_executable(bar dummy.cpp test.in)
2) The following causes the compile step for the dummy.cpp source file to
fail in presence of the custom command:
cmake_minimum_required(VERSION 3.2)
file(WRITE dummy.cpp int main() {})
add_custom_command(
OUTPUT test.out
COMMAND ${CMAKE_COMMAND} -E echo Hello World
MAIN_DEPENDENCY dummy.cpp
)
add_executable(foo dummy.cpp)
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
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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 prompted the creation of CMP0057
open for now.
Two related but distinct issues are triggered by the following test
cases with the Makefile generator:
1) The following causes the given custom command to be emitted for both
the foo and bar target which can lead to parallel build errors:
cmake_minimum_required(VERSION 3.2)
file(WRITE test.in)
file(WRITE dummy.cpp int main() {})
add_custom_command(
OUTPUT test.out
COMMAND ${CMAKE_COMMAND} -E echo Hello World
MAIN_DEPENDENCY test.in
)
add_executable(foo dummy.cpp test.in)
add_executable(bar dummy.cpp test.in)
2) The following causes the compile step for the dummy.cpp source file
to fail in presence of the custom command:
cmake_minimum_required(VERSION 3.2)
file(WRITE dummy.cpp int main() {})
add_custom_command(
OUTPUT test.out
COMMAND ${CMAKE_COMMAND} -E echo Hello World
MAIN_DEPENDENCY dummy.cpp
)
add_executable(foo dummy.cpp)
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
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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 targets, not multiple custom_commands within a single target. I'm fine with this policy as long as it captures the actual problem and doesn't break what already seemed to work just fine. 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. On Mon, Apr 27, 2015 at 7:39 AM Nils Gladitz nilsglad...@gmail.com wrote: 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 came up? I think I covered this in: http://www.cmake.org/Bug/view.php?id=15525#c38598 Issues I know of (two of which I reported; including the above) are: http://www.cmake.org/Bug/view.php?id=14550 http://www.cmake.org/Bug/view.php?id=15434 http://www.cmake.org/Bug/view.php?id=15525 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
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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 the remaining ones as phantom .rule files in the project. 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 came up? It is also somewhat non-sensical to use MAIN_DEPENDENCY for more than one rule for the same source file. The purpose of it is to attach the rule as the custom command for building the source file in VS IDE project files. VS allows only one custom command for building a given source. should I push/pop the policy in FindCUDA.cmake? No. Never set a policy to OLD in new code, and certainly not in upstream CMake. You could record in a source file property whether a source has been used as the MAIN_DEPENDENCY for something else and then use plain DEPENDS for later rules that depend on the source. -Brad -- 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
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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 came up? I think I covered this in: http://www.cmake.org/Bug/view.php?id=15525#c38598 Issues I know of (two of which I reported; including the above) are: http://www.cmake.org/Bug/view.php?id=14550 http://www.cmake.org/Bug/view.php?id=15434 http://www.cmake.org/Bug/view.php?id=15525 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
[cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
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 the project. I don't want to turn off the MAIN_DEPENDENCY feature, so should I push/pop the policy in FindCUDA.cmake? James -- 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
