Re: [CMake] Bug in SLN generation
Hi Scott. To file a bug, use the Mantis tracker at http://public.kitware.com/Bug/ As for running custom processing post-generation, there is no way hook this, and a request for it was explicitly declined: http://public.kitware.com/Bug/view.php?id=13020 Petr On Mon, Jan 5, 2015 at 8:53 PM, Scott Aron Bloom scott.bl...@onshorecs.com wrote: I have found a bug in SLN generation when the property USE_FOLDERS is set to on. The order of the folders, and vcprojects added to the folders is not sorted. It is sorted correctly if USE_FOLDERS is not set. I have two questions, first, what is the appropriate mechanism for filing a bug? I will create a trivial testcase to show the issue. Second, in the meantime I have a way to fix the sln file, as a post process after its generated. What type of rule could I add to the CMakeLists.txt file to run after the sln has been generated/updated by cmake? Scott -- 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 -- 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
Re: [cmake-developers] target_link_libraries and --start-group/--end-group ?
Hello, On 05/01/15 20:09, Robert Goulet wrote: My project needs to link with an external library which actually consist of a set of libraries. Adding these libs using target_link_libraries should be working just fine but unfortunately these libs have a bunch of circular dependencies, so it fails. In the makefile, we link with these libs using this syntax: -Wl,--start-group …libs… -Wl,--end-group …so that the linker is able to correctly find all symbols. What’s the proper way to deal with this using CMake? I tried to add the group flags to target_link_libraries but it does not work. Thanks! I'm not 100% sure that this also works with circular dependencies, but you could create an IMPORTED target per library and declare its dependencies via INTERFACE_LINK_LIBRARIES. Adding the imported ones to your executable should do the right thing. Thanks, Gregor PS: This list is mainly for development of CMake; cm...@cmake.org is for the actual consumers. -- 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-commits] CMake branch, next, updated. v3.1.0-1498-g56054b1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 56054b1982748475a350239ae42d99af0554242a (commit)
via 52d4ff49d973d77dba480e0b60b08c6c70e94538 (commit)
from 9b8ba31802a3e89b8aa1f34b3dfa7521d47c235a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56054b1982748475a350239ae42d99af0554242a
commit 56054b1982748475a350239ae42d99af0554242a
Merge: 9b8ba31 52d4ff4
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jan 5 05:57:28 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 5 05:57:28 2015 -0500
Merge topic 'FindCUDA-cross' into next
52d4ff49 Fix FindCUDA.cmake assumption about cross-compiling
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52d4ff49d973d77dba480e0b60b08c6c70e94538
commit 52d4ff49d973d77dba480e0b60b08c6c70e94538
Author: Mark Abraham mark.j.abra...@gmail.com
AuthorDate: Sun Jan 4 14:37:51 2015 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Mon Jan 5 11:56:50 2015 +0100
Fix FindCUDA.cmake assumption about cross-compiling
CMAKE_SYSTEM_PROCESSOR is not guaranteed to be defined (per
http://www.vtk.org/Wiki/CMake_Cross_Compiling), and when cross
compiling where it happens to be undefined, this module was broken.
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 29bb875..ecfc781 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -613,7 +613,7 @@ endif()
set(CUDA_VERSION_STRING ${CUDA_VERSION})
# Support for arm cross compilation with CUDA 5.5
-if(CUDA_VERSION VERSION_GREATER 5.0 AND CMAKE_CROSSCOMPILING AND
${CMAKE_SYSTEM_PROCESSOR} MATCHES arm AND EXISTS
${CUDA_TOOLKIT_ROOT_DIR}/targets/armv7-linux-gnueabihf)
+if(CUDA_VERSION VERSION_GREATER 5.0 AND CMAKE_CROSSCOMPILING AND
CMAKE_SYSTEM_PROCESSOR MATCHES arm AND EXISTS
${CUDA_TOOLKIT_ROOT_DIR}/targets/armv7-linux-gnueabihf)
set(CUDA_TOOLKIT_TARGET_DIR
${CUDA_TOOLKIT_ROOT_DIR}/targets/armv7-linux-gnueabihf CACHE PATH Toolkit
target location.)
else()
set(CUDA_TOOLKIT_TARGET_DIR ${CUDA_TOOLKIT_ROOT_DIR} CACHE PATH Toolkit
target location.)
@@ -621,7 +621,7 @@ endif()
mark_as_advanced(CUDA_TOOLKIT_TARGET_DIR)
# Target CPU architecture
-if(CUDA_VERSION VERSION_GREATER 5.0 AND CMAKE_CROSSCOMPILING AND
${CMAKE_SYSTEM_PROCESSOR} MATCHES arm)
+if(CUDA_VERSION VERSION_GREATER 5.0 AND CMAKE_CROSSCOMPILING AND
CMAKE_SYSTEM_PROCESSOR MATCHES arm)
set(_cuda_target_cpu_arch_initial ARM)
else()
set(_cuda_target_cpu_arch_initial )
---
Summary of changes:
Modules/FindCUDA.cmake |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.1.0-1496-g9b8ba31
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9b8ba31802a3e89b8aa1f34b3dfa7521d47c235a (commit)
via 6e977a761af4f38ad27dbdbc2e3777c780fb494e (commit)
from 4d0a5c05cec02e9b0ed8987621ae3a4f6a3b2428 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b8ba31802a3e89b8aa1f34b3dfa7521d47c235a
commit 9b8ba31802a3e89b8aa1f34b3dfa7521d47c235a
Merge: 4d0a5c0 6e977a7
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Jan 5 03:21:33 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 5 03:21:33 2015 -0500
Merge topic 'delete-algorithm' into next
6e977a76 Revert use of sfinae.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e977a761af4f38ad27dbdbc2e3777c780fb494e
commit 6e977a761af4f38ad27dbdbc2e3777c780fb494e
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Jan 5 09:19:59 2015 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Jan 5 09:20:11 2015 +0100
Revert use of sfinae.
VS 7.1 doesn't support sfinae.
diff --git a/Source/cmExportSetMap.cxx b/Source/cmExportSetMap.cxx
index 14c4458..5174118 100644
--- a/Source/cmExportSetMap.cxx
+++ b/Source/cmExportSetMap.cxx
@@ -25,7 +25,12 @@ cmExportSet* cmExportSetMap::operator[](const std::string
name)
void cmExportSetMap::clear()
{
- cmDeleteAll(*this);
+ for(std::mapstd::string, cmExportSet*::iterator it = this-begin();
+ it != this-end();
+ ++ it)
+{
+delete it-second;
+}
this-derived::clear();
}
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 1549322..721c2ab 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1510,7 +1510,11 @@ void cmGlobalGenerator::CreateGeneratorTargets()
//
void cmGlobalGenerator::ClearGeneratorMembers()
{
- cmDeleteAll(this-GeneratorTargets);
+ for(cmGeneratorTargetsType::iterator i = this-GeneratorTargets.begin();
+ i != this-GeneratorTargets.end(); ++i)
+{
+delete i-second;
+}
this-GeneratorTargets.clear();
cmDeleteAll(this-EvaluationFiles);
diff --git a/Source/cmStandardIncludes.h b/Source/cmStandardIncludes.h
index 4e846e6..853413d 100644
--- a/Source/cmStandardIncludes.h
+++ b/Source/cmStandardIncludes.h
@@ -448,22 +448,7 @@ private:
namespace ContainerAlgorithms {
-templatetypename struct voider { typedef void type; };
-
-templatetypename T, typename = void
-struct HasSecondType
-{
- enum { value = false };
-};
-
-templatetypename T
-struct HasSecondTypeT, typename voidertypename T::second_type::type
-{
- enum { value = true };
-};
-
-templatetypename Container,
-bool hasSecondType = HasSecondTypetypename Container::value_type::value
+templatetypename Container
struct DefaultDeleter
{
void operator()(typename Container::value_type value) {
@@ -471,10 +456,10 @@ struct DefaultDeleter
}
};
-templatetypename Container
-struct DefaultDeleterContainer, /* hasSecondType = */ true
+templatetypename K, typename V
+struct DefaultDeleterstd::mapK, V
{
- void operator()(typename Container::value_type value) {
+ void operator()(typename std::mapK, V::value_type value) {
delete value.second;
}
};
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 0eb47a9..3f09b9e 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -542,7 +542,12 @@ void cmTarget::ClearLinkMaps()
this-Internal-LinkInterfaceMap.clear();
this-Internal-LinkInterfaceUsageRequirementsOnlyMap.clear();
this-Internal-LinkClosureMap.clear();
- cmDeleteAll(this-LinkInformation);
+ for (cmTargetLinkInformationMap::const_iterator it
+ = this-LinkInformation.begin();
+ it != this-LinkInformation.end(); ++it)
+{
+delete it-second;
+}
this-LinkInformation.clear();
}
@@ -6908,7 +6913,10 @@ cmTargetLinkInformationMap
//
cmTargetLinkInformationMap::~cmTargetLinkInformationMap()
{
- cmDeleteAll(*this);
+ for(derived::iterator i = this-begin(); i != this-end(); ++i)
+{
+delete i-second;
+}
}
//
---
Summary of changes:
Source/cmExportSetMap.cxx|7 ++-
Source/cmGlobalGenerator.cxx |6 +-
Source/cmStandardIncludes.h | 23 ---
Source/cmTarget.cxx | 12 ++--
4 files changed, 25 insertions(+), 23 deletions(-)
Re: [cmake-developers] patch for FindCUDA.cmake
Am Montag, 5. Januar 2015, 00:22:51 schrieb Mark Abraham: On Sun, Jan 4, 2015 at 3:02 PM, Rolf Eike Beer e...@sf-mail.de wrote: Mark Abraham wrote: Hi, The FindCUDA.cmake module since v3.0 has had a bug because it assumes that when cross compiling that CMAKE_SYSTEM_PROCESSOR will be defined. That definition is documented as optional at http://www.vtk.org/Wiki/CMake_Cross_Compiling, and the module can't work if it happens to be undefined. Attached patch wraps the uses of CMAKE_SYSTEM_PROCESSOR in quotes so that interpolation will lead to the intended behaviour in all cases. The easier and better fix would be to just remove the dereference, i.e. if (… CMAKE_SYSTEM_PROCESSOR MATCHES arm …) True, once you look at the minutae of if(... MATCHES ...) :-) Updated patch attached. Fix pushed to next: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52d4ff49d973d77dba480e0b60b08c6c70e94538 Brad, it is based on release in case you want to pick it for 3.1.1. Eike signature.asc Description: This is a digitally signed message part. -- 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] FindCUDA ignores project dependencies when separable compilation is on
Just wanted to send this again, as the problem still exists. While working on the libdynd project (https://github.com/libdynd/libdynd), we've discovered two CUDA CMake issues that we'd like to help resolve. Who are the right people to speak with about these? Irwin Irwin Zaid wrote: Hi all, Just wanted to mention this issue I've run into. I have a project (libdynd -- https://github.com/libdynd/libdynd) that uses FindCUDA to deal with CUDA compilation. A part of our library is generated at compile-time, which we handle by the command add_dependencies(libdynd some_exe), where some_exe is an executable built with a custom command. This part of our library needs to be present before anything else is built. So far, everything has worked great, with and without CUDA. However, I found that by just turning separable compilation on, via set(CUDA_SEPARABLE_COMPILATION ON), the dependency I've added is then ignored and the necessary files are not generated. Basically, CMake goes straight to NVCC without running the custom command. This seems to me to be something wrong with FindCUDA, but it is of course possible that I've done something wrong. Any help would be appreciated! Irwin -- 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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk wrote: Hi James, Thanks for the quick reply! As I mentioned, we've hit two issues. The first is the project dependencies one, which I'll try and describe more a bit below. I'm not a CMake expert, so please bear with me. The second is what I've put under 2). The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. 1) Okay, I understand that, but I do think we saw a different behaviour when we switched to separable compilation. Let me describe what we are doing. We generate part of our library from a simple program (call the simple program 'gen', which generates a source file 'gen.hpp') that we want to execute before compiling our library (call our library 'main'). We set this up with the following: - add_executable(...) is called for 'gen' - add_custom_command(...) sets up a command that executes 'gen' - set_source_files_properties(...) is called to set 'gen.hpp' as having the PROPERTY of GENERATED - add_dependencies(main gen) is called to establish 'main' depends on 'gen' So far, this has only failed for CUDA with separable compilation. (It has worked for all of our other configurations. including CUDA without separable compilation.) Have we done something wrong? Is there some additional information we can look at to figure out what's going on? What kind of generator are you using (e.g. makefile)? Here's what I'm thinking might be the problem, though I'm not sure why it would have worked without CUDA_SEPARABLE_COMPILATION. There's a dependency between gen and gen.hpp (encoded in the call to add_custom_command(OUTPUTS gen.hpp COMMAND gen)). There's a dependency between main and gen (can't start building main until gen is built). There's a dependency between gen.hpp and main (gen.hpp is an input source to main, so it needs to be built as part of main). What I don't see is a dependency between gen.hpp and all the cuda sources that might use it as input. So from a dependency graph standpoint a makefile (if one is being used in this case) is entirely free to start compiling the CUDA code once the gen target has been satisfied. What you need is another target that builds the gen.hpp file which can be forced to run before main starts to build. There are more than one way to do this, and I'm not sure what the best option is, but you might try this: add_custom_command(OUTPUTS gen.hpp ) add_custom_target(make_gen_hpp DEPENDS gen.hpp) add_dependency(main make_gen_hpp) 2) A second problem we've run into is an error when trying to link a CUDA shared library with separable compilation. This is specifically a Linux problem, on Mac it is fine. A static library is also fine, working for both Linux and Mac. The particular error is relocation R_X86_64_32S against `__nv_module_id' can not be used when making a shared object; recompile with -fPIC. However, we are already compiling with -fPIC. I can confirm that -fPIC appears to be passed to both the host compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. This error occurs when trying to link all the different object files together of our library. Do you have any idea of what this could be? I'm not sure which object file wasn't compiled with -fPIC, but I would suspect it might be the intermediate link object file. FindCUDA is supposed to pass this flag along (see function(_cuda_get_important_host_flags)), but you might want to verify this with a 'make VERBOSE=1' and look for target_name_intermediate_link.o (substitute your target name in or leave it out of the search string). 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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
Alright, this is a lot of progress! 1) We are using Makefiles. I agree with you about the dependency graph, so I'll try and sort that out. I'll let you know what the result is. 2) I just checked and, indeed, the *_intermediate_link.o file is not being passed -fPIC. Is this our problem? What is the correct fix? Irwin James Bigler wrote: On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk mailto:irwin.z...@physics.ox.ac.uk wrote: Hi James, Thanks for the quick reply! As I mentioned, we've hit two issues. The first is the project dependencies one, which I'll try and describe more a bit below. I'm not a CMake expert, so please bear with me. The second is what I've put under 2). The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. 1) Okay, I understand that, but I do think we saw a different behaviour when we switched to separable compilation. Let me describe what we are doing. We generate part of our library from a simple program (call the simple program 'gen', which generates a source file 'gen.hpp') that we want to execute before compiling our library (call our library 'main'). We set this up with the following: - add_executable(...) is called for 'gen' - add_custom_command(...) sets up a command that executes 'gen' - set_source_files_properties(..__.) is called to set 'gen.hpp' as having the PROPERTY of GENERATED - add_dependencies(main gen) is called to establish 'main' depends on 'gen' So far, this has only failed for CUDA with separable compilation. (It has worked for all of our other configurations. including CUDA without separable compilation.) Have we done something wrong? Is there some additional information we can look at to figure out what's going on? What kind of generator are you using (e.g. makefile)? Here's what I'm thinking might be the problem, though I'm not sure why it would have worked without CUDA_SEPARABLE_COMPILATION. There's a dependency between gen and gen.hpp (encoded in the call to add_custom_command(OUTPUTS gen.hpp COMMAND gen)). There's a dependency between main and gen (can't start building main until gen is built). There's a dependency between gen.hpp and main (gen.hpp is an input source to main, so it needs to be built as part of main). What I don't see is a dependency between gen.hpp and all the cuda sources that might use it as input. So from a dependency graph standpoint a makefile (if one is being used in this case) is entirely free to start compiling the CUDA code once the gen target has been satisfied. What you need is another target that builds the gen.hpp file which can be forced to run before main starts to build. There are more than one way to do this, and I'm not sure what the best option is, but you might try this: add_custom_command(OUTPUTS gen.hpp ) add_custom_target(make_gen_hpp DEPENDS gen.hpp) add_dependency(main make_gen_hpp) 2) A second problem we've run into is an error when trying to link a CUDA shared library with separable compilation. This is specifically a Linux problem, on Mac it is fine. A static library is also fine, working for both Linux and Mac. The particular error is relocation R_X86_64_32S against `__nv_module_id' can not be used when making a shared object; recompile with -fPIC. However, we are already compiling with -fPIC. I can confirm that -fPIC appears to be passed to both the host compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. This error occurs when trying to link all the different object files together of our library. Do you have any idea of what this could be? I'm not sure which object file wasn't compiled with -fPIC, but I would suspect it might be the intermediate link object file. FindCUDA is supposed to pass this flag along (see function(_cuda_get_important_host_flags)), but you might want to verify this with a 'make VERBOSE=1' and look for target_name_intermediate_link.o (substitute your target name in or leave it out of the search string). 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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
2. It looks as though CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS is only
looking at the configuration specific flags. You can add the flag
specifically to all your configs (e.g. CMAKE_CXX_FLAGS_DEBUG) or you could
try adding these lines of code in your FindCUDA.cmake file somewhere
in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS after set(flags). It looks as
though this was overlooked (sorry).
set(important_host_flags)
_cuda_get_important_host_flags(important_host_flags
${CMAKE_${CUDA_C_OR_CXX}_FLAGS})
foreach(f ${important_host_flags})
list(APPEND flags -Xcompiler ${f})
endforeach()
On Mon, Jan 5, 2015 at 3:43 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk
wrote:
Alright, this is a lot of progress!
1) We are using Makefiles. I agree with you about the dependency graph, so
I'll try and sort that out. I'll let you know what the result is.
2) I just checked and, indeed, the *_intermediate_link.o file is not being
passed -fPIC. Is this our problem? What is the correct fix?
Irwin
James Bigler wrote:
On Mon, Jan 5, 2015 at 1:57 PM, Irwin Zaid irwin.z...@physics.ox.ac.uk
mailto:irwin.z...@physics.ox.ac.uk wrote:
Hi James,
Thanks for the quick reply! As I mentioned, we've hit two issues.
The first is the project dependencies one, which I'll try and
describe more a bit below. I'm not a CMake expert, so please bear
with me.
The second is what I've put under 2).
The only CMake build dependency changes when doing separable
compilation
are found in CUDA_LINK_SEPARABLE___COMPILATION_OBJECTS.
Basically what
this does is create a new rule to build an intermediate link
file. For
everything but some versions of MSVC generators it adds a custom
command
to generate this intermediate link file. The other case adds a
custom
command that runs as a PRE_LINK command to generate the object
file (the
reasons for this is a bug in VS custom command dependency
scanning), but
this should happen during link phase and not compile phase.
Nothing in here should change what happens before the target is
built,
though.
1) Okay, I understand that, but I do think we saw a different
behaviour when we switched to separable compilation. Let me describe
what we are doing.
We generate part of our library from a simple program (call the
simple program 'gen', which generates a source file 'gen.hpp') that
we want to execute before compiling our library (call our library
'main'). We set this up with the following:
- add_executable(...) is called for 'gen'
- add_custom_command(...) sets up a command that executes 'gen'
- set_source_files_properties(..__.) is called to set 'gen.hpp' as
having the PROPERTY of GENERATED
- add_dependencies(main gen) is called to establish 'main' depends
on 'gen'
So far, this has only failed for CUDA with separable compilation.
(It has worked for all of our other configurations. including CUDA
without separable compilation.)
Have we done something wrong? Is there some additional information
we can look at to figure out what's going on?
What kind of generator are you using (e.g. makefile)?
Here's what I'm thinking might be the problem, though I'm not sure why
it would have worked without CUDA_SEPARABLE_COMPILATION.
There's a dependency between gen and gen.hpp (encoded in the call to
add_custom_command(OUTPUTS gen.hpp COMMAND gen)).
There's a dependency between main and gen (can't start building main
until gen is built).
There's a dependency between gen.hpp and main (gen.hpp is an input
source to main, so it needs to be built as part of main).
What I don't see is a dependency between gen.hpp and all the cuda
sources that might use it as input. So from a dependency graph
standpoint a makefile (if one is being used in this case) is entirely
free to start compiling the CUDA code once the gen target has been
satisfied.
What you need is another target that builds the gen.hpp file which can
be forced to run before main starts to build. There are more than one
way to do this, and I'm not sure what the best option is, but you might
try this:
add_custom_command(OUTPUTS gen.hpp )
add_custom_target(make_gen_hpp DEPENDS gen.hpp)
add_dependency(main make_gen_hpp)
2) A second problem we've run into is an error when trying to link a
CUDA shared library with separable compilation. This is specifically
a Linux problem, on Mac it is fine. A static library is also fine,
working for both Linux and Mac.
The particular error is relocation R_X86_64_32S against
`__nv_module_id' can not be used when making a shared object;
recompile with -fPIC. However, we are already compiling with -fPIC.
I can confirm that -fPIC appears to be passed to both the host
[Cmake-commits] CMake branch, master, updated. v3.1.0-600-g73144c0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 73144c098d8b176bb99b762450b9b231687011b8 (commit) from 4b70635c9fe9b4425db275c2ed3be1b5223ebe4b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=73144c098d8b176bb99b762450b9b231687011b8 commit 73144c098d8b176bb99b762450b9b231687011b8 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Jan 6 00:01:12 2015 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Jan 6 00:01:12 2015 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 506f0da..9515372 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 1) -set(CMake_VERSION_PATCH 20150105) +set(CMake_VERSION_PATCH 20150106) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. On Mon, Jan 5, 2015 at 5:32 AM, Irwin Zaid irwin.z...@physics.ox.ac.uk wrote: Just wanted to send this again, as the problem still exists. While working on the libdynd project (https://github.com/libdynd/libdynd), we've discovered two CUDA CMake issues that we'd like to help resolve. Who are the right people to speak with about these? Irwin Irwin Zaid wrote: Hi all, Just wanted to mention this issue I've run into. I have a project (libdynd -- https://github.com/libdynd/libdynd) that uses FindCUDA to deal with CUDA compilation. A part of our library is generated at compile-time, which we handle by the command add_dependencies(libdynd some_exe), where some_exe is an executable built with a custom command. This part of our library needs to be present before anything else is built. So far, everything has worked great, with and without CUDA. However, I found that by just turning separable compilation on, via set(CUDA_SEPARABLE_COMPILATION ON), the dependency I've added is then ignored and the necessary files are not generated. Basically, CMake goes straight to NVCC without running the custom command. This seems to me to be something wrong with FindCUDA, but it is of course possible that I've done something wrong. Any help would be appreciated! Irwin -- 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 -- 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
[Cmake-commits] CMake branch, next, updated. v3.1.0-1502-gbe2007b
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via be2007b08096c2ca1323141d07811f8018151e24 (commit)
via c4e743674f3f7c576ff90cacae6465e7e171faed (commit)
via 4b70635c9fe9b4425db275c2ed3be1b5223ebe4b (commit)
via 592dd355705ba0b22f33d48c2e0b5ff0e2a471d8 (commit)
from 56054b1982748475a350239ae42d99af0554242a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=be2007b08096c2ca1323141d07811f8018151e24
commit be2007b08096c2ca1323141d07811f8018151e24
Merge: 56054b1 c4e7436
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Mon Jan 5 13:54:25 2015 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 5 13:54:25 2015 -0500
Merge topic 'fix-error-message-typo-tar-cmd' into next
c4e74367 cmcmd: fix copy/paste typo in '-E tar t' command
4b70635c CMake Nightly Date Stamp
592dd355 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4e743674f3f7c576ff90cacae6465e7e171faed
commit c4e743674f3f7c576ff90cacae6465e7e171faed
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Mon Jan 5 13:53:53 2015 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Mon Jan 5 13:53:53 2015 -0500
cmcmd: fix copy/paste typo in '-E tar t' command
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index a97444d..37d2916 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -753,7 +753,7 @@ int cmcmd::ExecuteCMakeCommand(std::vectorstd::string
args)
{
if ( !cmSystemTools::ListTar(outFile.c_str(), gzip, verbose) )
{
- cmSystemTools::Error(Problem creating tar: , outFile.c_str());
+ cmSystemTools::Error(Problem listing tar: , outFile.c_str());
return 1;
}
}
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
Source/cmcmd.cxx |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[cmake-developers] target_link_libraries and --start-group/--end-group ?
Hi, My project needs to link with an external library which actually consist of a set of libraries. Adding these libs using target_link_libraries should be working just fine but unfortunately these libs have a bunch of circular dependencies, so it fails. In the makefile, we link with these libs using this syntax: -Wl,--start-group ...libs... -Wl,--end-group ...so that the linker is able to correctly find all symbols. What's the proper way to deal with this using CMake? I tried to add the group flags to target_link_libraries but it does not work. Thanks! Robert Goulet Senior Software Developer Games Solutions Group Autodesk Media Entertainment MAIN +1 514 393 1616 DIRECT +1 514 954 3911 MOBILE +1 438 397 4075 Autodesk, Inc. 10 Rue Duke Montreal, QC, H3C 2L7 www.autodesk.comhttp://www.autodesk.com/ [Description: Email_Signature_Logobar] -- 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] IMPLICIT_DEPENDS and removal of dependencies
If I have a file that depended on another file (say file.cpp includes a.h which includes b.h), and then I rename b.h to c.h is CMake able to detect that b.h no longer exists on disk and remove the dependency from the makefiles? Right now the makefile still has a dependency to b.h which it cannot resolve preventing compilation. I've run a configure/generate step with cmake, but dependencies to b.h persist. I'm using CMake 3.0.2. Thanks, 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
[CMake] Bug in SLN generation
I have found a bug in SLN generation when the property USE_FOLDERS is set to on. The order of the folders, and vcprojects added to the folders is not sorted. It is sorted correctly if USE_FOLDERS is not set. I have two questions, first, what is the appropriate mechanism for filing a bug? I will create a trivial testcase to show the issue. Second, in the meantime I have a way to fix the sln file, as a post process after its generated. What type of rule could I add to the CMakeLists.txt file to run after the sln has been generated/updated by cmake? Scott -- 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
[CMake] CMake 3.1 and add_executable() without sources
Hi, I am wondering now that 3.1 is out if using add_executable() without sources and later using target_sources() is a new supported way of creating targets? The docs don’t actually say the sources are optional and you can later use target_sources(). We currently have several macros we reuse for multiple targets across multiple projects but currently require 2 separate macros per functionality to specify target sources (via a shared per-target global variable - yuck) and another for linker options. With 3.1 we can combine these into a single macro without the global var which simplifies our CMakeLists files greatly. But before I start doing this, I want to make sure this an acceptable way going forward. Thanks, Kevin -- 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
Re: [CMake] FindCUDA ignores project dependencies when separable compilation is on
Hi James, Thanks for the quick reply! As I mentioned, we've hit two issues. The first is the project dependencies one, which I'll try and describe more a bit below. I'm not a CMake expert, so please bear with me. The second is what I've put under 2). The only CMake build dependency changes when doing separable compilation are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what this does is create a new rule to build an intermediate link file. For everything but some versions of MSVC generators it adds a custom command to generate this intermediate link file. The other case adds a custom command that runs as a PRE_LINK command to generate the object file (the reasons for this is a bug in VS custom command dependency scanning), but this should happen during link phase and not compile phase. Nothing in here should change what happens before the target is built, though. 1) Okay, I understand that, but I do think we saw a different behaviour when we switched to separable compilation. Let me describe what we are doing. We generate part of our library from a simple program (call the simple program 'gen', which generates a source file 'gen.hpp') that we want to execute before compiling our library (call our library 'main'). We set this up with the following: - add_executable(...) is called for 'gen' - add_custom_command(...) sets up a command that executes 'gen' - set_source_files_properties(...) is called to set 'gen.hpp' as having the PROPERTY of GENERATED - add_dependencies(main gen) is called to establish 'main' depends on 'gen' So far, this has only failed for CUDA with separable compilation. (It has worked for all of our other configurations. including CUDA without separable compilation.) Have we done something wrong? Is there some additional information we can look at to figure out what's going on? 2) A second problem we've run into is an error when trying to link a CUDA shared library with separable compilation. This is specifically a Linux problem, on Mac it is fine. A static library is also fine, working for both Linux and Mac. The particular error is relocation R_X86_64_32S against `__nv_module_id' can not be used when making a shared object; recompile with -fPIC. However, we are already compiling with -fPIC. I can confirm that -fPIC appears to be passed to both the host compiler for non-CUDA source and via -Xcompiler -fPIC for CUDA source. This error occurs when trying to link all the different object files together of our library. Do you have any idea of what this could be? -- Thanks for all of your help. Cheers, Irwin -- 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
[cmake-developers] [CMake 0015336]: When property USE_FOLDERS is ON, the generated VS solution is not sorted propertly
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15336 == Reported By:Scott Aron Bloom Assigned To: == Project:CMake Issue ID: 15336 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-01-05 16:13 EST Last Modified: 2015-01-05 16:13 EST == Summary:When property USE_FOLDERS is ON, the generated VS solution is not sorted propertly Description: WHen I turn on the USE_FOLDERS property, via set_property(GLOBAL PROPERTY USE_FOLDERS ON), and set the appropriate property on each project, the folders are not added to the top level solution in a sorted manner. Also, the projects themselves are not added to the folder in a sorted manner. Steps to Reproduce: Run cmake on the attached project == Issue History Date ModifiedUsername FieldChange == 2015-01-05 16:13 Scott Aron BloomNew Issue 2015-01-05 16:13 Scott Aron BloomFile Added: lab5.zip == -- 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] target_link_libraries and --start-group/--end-group ?
I believe what you want to do is bring the libraries in as imported targets and set the target property IMPORTED_LINK_INTERFACE_MULTIPLICITY ( http://www.cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LINK_INTERFACE_MULTIPLICITY.html ). By default the value should be 2 which means that we will list all static libraries twice, but you might need to increase the value. I would also read the resolution of bug 14463 ( http://public.kitware.com/Bug/view.php?id=14463) for a quick explanation of how the target_link_libraries order determines the static link ordering. On Mon, Jan 5, 2015 at 2:09 PM, Robert Goulet robert.gou...@autodesk.com wrote: Hi, My project needs to link with an external library which actually consist of a set of libraries. Adding these libs using target_link_libraries should be working just fine but unfortunately these libs have a bunch of circular dependencies, so it fails. In the makefile, we link with these libs using this syntax: -Wl,--start-group …libs… -Wl,--end-group …so that the linker is able to correctly find all symbols. What’s the proper way to deal with this using CMake? I tried to add the group flags to target_link_libraries but it does not work. Thanks! *Robert Goulet* Senior Software Developer Games Solutions Group Autodesk Media Entertainment *MAIN* +1 514 393 1616 *DIRECT* +1 514 954 3911 *MOBILE* +1 438 397 4075 *Autodesk, Inc.* 10 Rue Duke Montreal, QC, H3C 2L7 www.autodesk.com [image: Description: Email_Signature_Logobar] -- 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 -- 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
