[CMake] CXX and CUDACXX
Hi All, I'd like to understand the expectations with CMake 3.12+ with the following setup. project(foo LANGUAGES CXX CUDA) By default, should the CUDACXX compiler be using the found compiler for CXX for host-side compilation? What I'm seeing is that host-side compilation for CUDA is not passing -ccbin to NVCC or setting up the environment in a way that nvcc will use the CXX configured compiler but rather just using the c++ it finds on PATH. Is there a best practice for telling the CUDA language to use the CXX settings for host-side compilation? Thanks! -- 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: https://cmake.org/mailman/listinfo/cmake
[CMake] ctest // fixtures and --repeat-until-fail
Hello All, Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with --repeat-until-fail option? My expectation, if I requesting a test run for example 10 times, the sequence should be as follows: fixture_setup, then test, then fixture_cleanup repeats 10 times But in practice, I've got following sequence 1. fixture_setup runs 10 times 2. test runs 10 times 3. fixture_cleanup runs 10 times Is it expected behavior? I'm using ctest version 3.14.2 Thank you in advance. -- Best Regards, Sergei Nikulov -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest // fixtures and --repeat-until-fail
> > On Tue, Apr 16, 2019 at 10:07 PM Sergei Nikulov > wrote: >> >> Hello All, >> >> Has anybody knows how FIXTURES_SETUP/FIXTURES_CLEANUP should work with >> --repeat-until-fail option? >> >> My expectation, if I requesting a test run for example 10 times, the >> sequence should be as follows: >> >> fixture_setup, then test, then fixture_cleanup repeats 10 times >> >> But in practice, I've got following sequence >> >> 1. fixture_setup runs 10 times >> 2. test runs 10 times >> 3. fixture_cleanup runs 10 times >> >> Is it expected behavior? >> I'm using ctest version 3.14.2 > > > The documentation for the --repeat-until-fail option says "Require each test > to run times without failing in order to pass". A fixture setup or > cleanup test is still a test, so they will also be run times. The logic > that implements repeating tests sets up a counter on each test and it runs > that test times before marking that test as complete. This is why you see > fixture_setup run 10 times, then test runs 10 times and lastly > fixture_cleanup runs 10 times. > I understand that fixture is still a test. To achieve repeatable behavior -R "test_continues_*" is enough. But if it calls FIXTURE why not apply the specific behavior as expected from fixture (init/teardown)? -- Best Regards, Sergei Nikulov -- 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: https://cmake.org/mailman/listinfo/cmake
[CMake] Correct use of VS_DEBUGGER_WORKING_DIRECTORY etc.
I’m trying to use the new VS_DEBUGGER_WORKING_DIRECTORY and VS_DEBUGGER_COMMAND properties to facilitate debugging in a CMake-generated Visual Studio project file (in my case Visual Studio 2013). Everything else in my configuration works except this… I’ve noted from ‘regular’ Visual Studio project files (i.e. ones not generated from CMake that, in the “Configuration Properties/Debugging” dialog, the ‘Command’ and ‘Working Directory’ fields are populated by default with $(TargetPath) and $(TargetDir) respectively. So in my CMakeLists.txt file, I have: set_target_properties(myApplication PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY "$(TargetDir)" VS_DEBUGGER_COMMAND"$(TargetPath)" VS_DEBUGGER_ENVIRONMENT "%PATH%;C:\\Qt\\5.9.7\\msvc2013_64\\bin") [In fact I've tried this with and without the quotes around $(TargetDir) and $(TargetPath) and the result is the same each time; they're absolutely necessary around the path.] What happens is that I then build the application, go to the “Configuration Properties/Debugging” dialog and verify that it looks exactly the same as a normal project file, with $(TargetDir) and $(TargetPath) appearing exactly where they should do. It doesn't work though; when I try to debug I get a message saying "Unable to start debugging. Check your debugger settings..." So I delete the text $(TargetDir) and $(TargetPath) from the dialog, then type them in again exactly as before: and then it works perfectly. What am I doing wrong? -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CXX and CUDACXX
The default implementation is to defer to CUDA for selecting what ever host compiler it would like. To make sure that CMake uses the same CXX and CUDACXX compiler you will need to explicitly state that either through the CUDAHOSTCXX env variable ( https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CXX and CUDACXX
I don't have any other suggestions. In general I recommend the script approach or using enable_language(CUDA). The enable_language approach should work, so I am curious what other issues you are seeing. On Tue, Apr 16, 2019 at 2:24 PM Dustyn Blasig wrote: > > Thx for the info. > > Since CXX and CUDA are defined together in the project() command, I don't see > a way to inject code to use the CXX compiler if no CUDAHOSTCXX or > CMAKE_CUDA_HOST_COMPILER is given without replicating the CXX search. I tried > moving CUDA out to an enable_language(CUDA) call instead so I could set those > variables between project(foo LANGUAGES CXX) and enable_language(CUDA), but > I'm seeing other issues with that approach. > > Any other suggestions? If not, we'll just wrap our cmake invocation in a > script to help setup the environment properly for now. > > Thx! > > On Tue, Apr 16, 2019 at 1:10 PM Robert Maynard > wrote: >> >> The default implementation is to defer to CUDA for selecting what >> ever host compiler it would like. To make sure that CMake uses the >> same CXX and CUDACXX compiler you will need to explicitly state that >> either through the CUDAHOSTCXX env variable ( >> https://cmake.org/cmake/help/v3.12/envvar/CUDAHOSTCXX.html ) or with >> CMAKE_CUDA_HOST_COMPILER on the initial configuration of a project. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How to generate a non-standard platform and non-standard project file with the Visual studio generator
OK, no response yet. I'm not sure if that means this is a problem that isn't
interesting to most or if it is a good hard problem that no one knows how to
solve.
Thinking a little more, I'm starting to lean toward a solution where I have a
build_src folder where I put something like the sample .vcxproj file that I
pasted in my first e-mail. I can update the file substituting CMake variables
for some of the information that needs to be updated and use
configure_package_config_file() to replace the data according to the execution
of cmake against the current CMakeLists.txt file. Then, maybe I could copy the
output file over the standard cmake process generated .vcxproj file as a post
build step. Not sure if this would work, particularly the bit about copying
over the standard .vcxproj file, but one way to find out, right?
This is the approach I'm going to attempt unless anyone has a better
suggestion. Trying not to beg for help here.
-Original Message-
From: CMake On Behalf Of j...@22ndtech.com
Sent: Sunday, April 14, 2019 9:27 PM
To: cmake@cmake.org
Subject: [CMake] How to generate a non-standard platform and non-standard
project file with the Visual studio generator
Hi all,
Do you have any suggestions for generation of a non-standard platform and
project file from Visual Studio. I'm trying to generate a file compatible with
the Magic Leap Visual Studio Extension. The first problem I have is that the
platform is ML, not the standard x86 or x64. The next problem is that it is
not a standard msbuild project file, but an nmake file. I've included the
.vcxproj file from their simple OpenGL app sample below.
http://schemas.microsoft.com/developer/msbuild/2003;>
Debug
ML
Release
ML
Debug
x64
Release
x64
{"$mlprojguid$"}
$mlprojfile$
$mlprojkind$
$ml_mfit_extra_args$
True
Makefile
$platformtoolset$
Makefile
$platformtoolset$
Makefile
$platformtoolset$
Makefile
$platformtoolset$
false
false
Project
PropertySheet
File
$mlsdkpath$
$device_debug_certificate$
$ml_extra_build_options$
$device_debug_full_spec$
$(MLSDK);$(PATH)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
device_debug -v --set-options=ide/visualstudio
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
device_debug -r -v --set-options=ide/visualstudio
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
device_debug -c -v --set-options=ide/visualstudio
$(MLExtraBuildOption)
$device_debug_preprocessor_defines$
$device_debug_include_paths$
$(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is.
h
$device_debug_packagefile$
$device_debug_outputdir$
$(ProjectDir)\$(IntDir)
$(IntDir)\$device_debug_outputfile$
$(NMakeOutput)
MLDebugger
false
true
main
true
true
$mlsdkpath$
$device_release_certificate$
$ml_extra_build_options$
$device_release_full_spec$
$(MLSDK);$(PATH)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
device_release -v --set-options=ide/visualstudio
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
device_release -r -v --set-options=ide/visualstudio
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
device_release -c -v --set-options=ide/visualstudio
$(MLExtraBuildOption)
$device_release_preprocessor_defines$
$device_release_include_paths$
$(LOCALAPPDATA)\Microsoft\VisualStudio\MagicLeap\ml_is.
h
$device_release_packagefile$
$device_release_outputdir$
$(ProjectDir)\$(IntDir)
$(IntDir)\$device_release_outputfile$
$(NMakeOutput)
MLDebugger
false
false
true
true
$mlsdkpath$
$host_debug_certificate$
$ml_extra_build_options$
$host_debug_full_spec$
$(MLSDK);$(PATH)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
msvc-$msvcversion$_debug -v VCDIR="$(VCInstallDir)
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
msvc-$msvcversion$_debug -r -v VCDIR="$(VCInstallDir)
$(MLExtraBuildOption)
mabu $(MLProjectFile) MLSDK="$(MLSDK)" -t
msvc-$msvcversion$_debug -c -v VCDIR="$(VCInstallDir)
$(MLExtraBuildOption)
$host_debug_preprocessor_defines$
$host_debug_include_paths$
$host_debug_packagefile$
$host_debug_outputdir$
$(ProjectDir)\$(IntDir)
$(IntDir)\$host_debug_outputfile$
WindowsLocalDebugger
false
true
PATH=$(MLSDK)\VirtualDevice\bin;$(MLSDK)\VirtualDe
vice\lib;$(MLSDK)\lib\win64
$(ProjectDir)\$ml_asset_folder$
$mlsdkpath$
$host_release_certificate$
$ml_extra_build_options$
[Cmake-commits] CMake branch, release, updated. v3.14.2-6-g09fba61
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, release has been updated via 09fba6146fa726a83cbbccc3d5fb288f7f14f111 (commit) via 0b54f72e940503adfbd978d7f1dedc3da4799f52 (commit) via cce342a5b966c57d933951053757090fc860a067 (commit) via a0b6448c855053301cba575c226abecef173f2c3 (commit) from a6bf68141faca9af22624c8d0e1603653a73fce4 (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 - --- Summary of changes: Modules/FindBoost.cmake | 2 +- Modules/InstallRequiredSystemLibraries.cmake | 7 +-- Tests/FindBoost/CMakeLists.txt | 13 + Tests/FindBoost/TestPython/CMakeLists.txt| 17 + 4 files changed, 36 insertions(+), 3 deletions(-) create mode 100644 Tests/FindBoost/TestPython/CMakeLists.txt hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.14.2-731-g2d37678
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 2d3767822662ad3f19190eb5a84b43becdb84a1f (commit)
via d145d72e708b7d742fb1324c056ba2c0254dda76 (commit)
from 9aecda56ba960267b392e54e5c28388a6cfa92ed (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d3767822662ad3f19190eb5a84b43becdb84a1f
commit 2d3767822662ad3f19190eb5a84b43becdb84a1f
Merge: 9aecda5 d145d72
Author: Brad King
AuthorDate: Tue Apr 16 17:43:42 2019 +
Commit: Kitware Robot
CommitDate: Tue Apr 16 13:43:52 2019 -0400
Merge topic 'vs-project-import'
d145d72e70 VS: add target property VS_PROJECT_IMPORT_
Acked-by: Kitware Robot
Merge-request: !3143
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d145d72e708b7d742fb1324c056ba2c0254dda76
commit d145d72e708b7d742fb1324c056ba2c0254dda76
Author: Leonid Pospelov
AuthorDate: Sun Mar 24 04:47:53 2019 +0300
Commit: Brad King
CommitDate: Mon Apr 15 13:05:07 2019 -0400
VS: add target property VS_PROJECT_IMPORT_
Fixes: #18998
diff --git a/Help/manual/cmake-properties.7.rst
b/Help/manual/cmake-properties.7.rst
index 4d4b9ff..bd19ccf 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -335,6 +335,7 @@ Properties on Targets
/prop_tgt/VS_KEYWORD
/prop_tgt/VS_MOBILE_EXTENSIONS_VERSION
/prop_tgt/VS_NO_SOLUTION_DEPLOY
+ /prop_tgt/VS_PROJECT_IMPORT
/prop_tgt/VS_SCC_AUXPATH
/prop_tgt/VS_SCC_LOCALPATH
/prop_tgt/VS_SCC_PROJECTNAME
diff --git a/Help/prop_tgt/VS_PROJECT_IMPORT.rst
b/Help/prop_tgt/VS_PROJECT_IMPORT.rst
new file mode 100644
index 000..569c8ea
--- /dev/null
+++ b/Help/prop_tgt/VS_PROJECT_IMPORT.rst
@@ -0,0 +1,8 @@
+VS_PROJECT_IMPORT
+-
+
+Visual Studio managed project imports
+
+Adds to a generated Visual Studio project one or more semicolon-delimited paths
+to .props files needed when building projects from some NuGet packages.
+For example, ``my_packages_path/MyPackage.1.0.0/build/MyPackage.props``.
diff --git a/Help/release/dev/vs-project-import.rst
b/Help/release/dev/vs-project-import.rst
new file mode 100644
index 000..de6024d
--- /dev/null
+++ b/Help/release/dev/vs-project-import.rst
@@ -0,0 +1,5 @@
+vs-project-import
+-
+
+* The :prop_tgt:`VS_PROJECT_IMPORT` target property was added which allows
+ to import external .props files in managed Visual Studio targets.
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index 5c9f25e..6ec47c2 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -662,6 +662,7 @@ void cmVisualStudio10TargetGenerator::Generate()
this->WriteCustomCommands(e0);
this->WriteAllSources(e0);
this->WriteDotNetReferences(e0);
+this->WriteImports(e0);
this->WriteEmbeddedResourceGroup(e0);
this->WriteXamlFilesGroup(e0);
this->WriteWinRTReferences(e0);
@@ -810,6 +811,24 @@ void cmVisualStudio10TargetGenerator::WriteDotNetReference(
this->WriteDotNetReferenceCustomTags(e2, ref);
}
+void cmVisualStudio10TargetGenerator::WriteImports(Elem& e0)
+{
+ const char* imports =
+this->GeneratorTarget->Target->GetProperty("VS_PROJECT_IMPORT");
+ if (imports) {
+std::vector argsSplit;
+cmSystemTools::ExpandListArgument(std::string(imports), argsSplit, false);
+for (auto& path : argsSplit) {
+ if (!cmsys::SystemTools::FileIsFullPath(path)) {
+path = this->Makefile->GetCurrentSourceDirectory() + "/" + path;
+ }
+ ConvertToWindowsSlash(path);
+ Elem e1(e0, "Import");
+ e1.Attribute("Project", path);
+}
+ }
+}
+
void cmVisualStudio10TargetGenerator::WriteDotNetReferenceCustomTags(
Elem& e2, std::string const& ref)
{
diff --git a/Source/cmVisualStudio10TargetGenerator.h
b/Source/cmVisualStudio10TargetGenerator.h
index 5901004..b5b7a4a 100644
--- a/Source/cmVisualStudio10TargetGenerator.h
+++ b/Source/cmVisualStudio10TargetGenerator.h
@@ -76,6 +76,7 @@ private:
void WriteDotNetReference(Elem& e1, std::string const& ref,
std::string const& hint,
std::string const& config);
+ void WriteImports(Elem& e0);
void WriteDotNetReferenceCustomTags(Elem& e2, std::string const& ref);
void WriteEmbeddedResourceGroup(Elem& e0);
void WriteWinRTReferences(Elem& e0);
diff --git a/Tests/RunCMake/VS10Project/RunCMakeTest.cmake
b/Tests/RunCMake/VS10Project/RunCMakeTest.cmake
index df253a9..219e529 100644
--- a/Tests/RunCMake/VS10Project/RunCMakeTest.cmake
+++
[Cmake-commits] CMake branch, master, updated. v3.14.2-732-g8d5eb97
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 8d5eb9787885d21d5d20630473c11a79250ca28e (commit) from 2d3767822662ad3f19190eb5a84b43becdb84a1f (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 - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d5eb9787885d21d5d20630473c11a79250ca28e commit 8d5eb9787885d21d5d20630473c11a79250ca28e Author: Kitware Robot AuthorDate: Wed Apr 17 00:01:04 2019 -0400 Commit: Kitware Robot CommitDate: Wed Apr 17 00:01:04 2019 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 636d332..b7b278b 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 14) -set(CMake_VERSION_PATCH 20190416) +set(CMake_VERSION_PATCH 20190417) #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 https://cmake.org/mailman/listinfo/cmake-commits
