[cmake-developers] [CMake 0016027]: nvcc encloses -ccbin argument with gratuitous quotation marks during intermediate-link phase
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=16027 == Reported By:Eyal Rozenberg Assigned To: == Project:CMake Issue ID: 16027 Category: Modules Reproducibility:sometimes Severity: minor Priority: normal Status: new == Date Submitted: 2016-03-21 17:06 EDT Last Modified: 2016-03-21 17:06 EDT == Summary:nvcc encloses -ccbin argument with gratuitous quotation marks during intermediate-link phase Description: I've been using CMake on Debian Stretch with CUDA. I'm not sure what the version was until recently, but everything worked fine for me. Then I started getting errors such as: "/usr/local/cuda/bin/gcc": No such file or directory CMakeFiles/tester.dir/build.make:2335: recipe for target 'CMakeFiles/wherever/foo.o' failed The culprit seems to be /usr/share/cmake/Modules/FindCUDA.cmake, line 1554. Pseudo-patch: - list(APPEND nvcc_flags -ccbin "\"${CUDA_HOST_COMPILER}\"") + list(APPEND nvcc_flags -ccbin "${CUDA_HOST_COMPILER}") that resolves the issue. Steps to Reproduce: 1. export CC=/link/to/your/appropriate/gcc 2. cmake a project with CMakeList.txt which finds CUDA and with set(CUDA_SEPARABLE_COMPILATION ON) 3. Build the project The .cu files will compile, the intermediate-link phase won't pass == Issue History Date ModifiedUsername FieldChange == 2016-03-21 17:06 Eyal Rozenberg New Issue == -- 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] Startup Project Configuration [mantis 15578]
On Fri, Mar 18, 2016 at 1:31 PM, Brad Kingwrote: > > Please check that the revised version works for you. I did some more thorough testing and ran into an issue when USE_FOLDERS is enabled. The problem is actually the same one affecting the ALL_BUILD target that is preventing it from being grouped with the PREDEFINED_TARGETS_FOLDER as it should be. It's not actually the first target in a .sln file that is treated as the default startup project, but rather the first _fully defined target_. See this SO comment thread: http://stackoverflow.com/questions/694730/why-is-set-as-startup-option-stored-in-the-suo-file-and-not-the-sln-file#comment40597475_1808352 The solution is to just list all folders in the .sln file first (patch 0002). With the fix in patch 0002, ALL_BUILD can then be put in PREDEFINED_TARGETS_FOLDER (patch 0003). Taylor From 2e4adaba69cd61143c468dc50b9bc82a06d5e484 Mon Sep 17 00:00:00 2001 From: Taylor Braun-Jones Date: Mon, 21 Mar 2016 14:34:34 -0400 Subject: [PATCH 1/3] fixup! VS: Add option to choose the `.sln` startup project (#15578) Change `getFirstProject` macro to more flexible version `getProjectNames` --- Tests/RunCMake/VSSolution/StartupProject-check.cmake | 3 ++- .../RunCMake/VSSolution/StartupProjectMissing-check.cmake | 3 ++- Tests/RunCMake/VSSolution/solution_parsing.cmake | 15 --- 3 files changed, 12 insertions(+), 9 deletions(-) diff --git a/Tests/RunCMake/VSSolution/StartupProject-check.cmake b/Tests/RunCMake/VSSolution/StartupProject-check.cmake index fd7cc28..8890334 100644 --- a/Tests/RunCMake/VSSolution/StartupProject-check.cmake +++ b/Tests/RunCMake/VSSolution/StartupProject-check.cmake @@ -1,4 +1,5 @@ -getFirstProject(first_project StartupProject) +getProjectNames(projects) +list(GET projects 0 first_project) if(NOT first_project STREQUAL "ZERO_CHECK") error("ZERO_CHECK is not the startup project") endif() diff --git a/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake b/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake index 95fede7..b1017dd 100644 --- a/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake +++ b/Tests/RunCMake/VSSolution/StartupProjectMissing-check.cmake @@ -1,4 +1,5 @@ -getFirstProject(first_project StartupProjectMissing) +getProjectNames(projects) +list(GET projects 0 first_project) if(NOT first_project STREQUAL "ALL_BUILD") error("ALL_BUILD is not the startup project") endif() diff --git a/Tests/RunCMake/VSSolution/solution_parsing.cmake b/Tests/RunCMake/VSSolution/solution_parsing.cmake index 001b584..4e5bb59 100644 --- a/Tests/RunCMake/VSSolution/solution_parsing.cmake +++ b/Tests/RunCMake/VSSolution/solution_parsing.cmake @@ -50,17 +50,18 @@ macro(parseGlobalSections arg_out_pre arg_out_post testName) endmacro() -macro(getFirstProject arg_out_first_project testName) - set(${arg_out_first_project} "") - set(sln "${RunCMake_TEST_BINARY_DIR}/${testName}.sln") +macro(getProjectNames arg_out_projects) + set(${arg_out_projects} "") + set(sln "${RunCMake_TEST_BINARY_DIR}/${test}.sln") if(NOT EXISTS "${sln}") error("Expected solution file ${sln} does not exist") endif() file(STRINGS "${sln}" project_lines REGEX "^Project\\(") - list(GET project_lines 0 first_project) - string(REGEX REPLACE ".* = \"" "" first_project "${first_project}") - string(REGEX REPLACE "\", .*" "" first_project "${first_project}") - set(${arg_out_first_project} "${first_project}") + foreach(project_line IN LISTS project_lines) +string(REGEX REPLACE ".* = \"" "" project_line "${project_line}") +string(REGEX REPLACE "\", .*" "" project_line "${project_line}") +list(APPEND ${arg_out_projects} "${project_line}") + endforeach() endmacro() -- 2.7.2.windows.1 From 898826c3dfb86078c6b42578d4bb5ae991552ecc Mon Sep 17 00:00:00 2001 From: Taylor Braun-Jones Date: Mon, 21 Mar 2016 16:01:20 -0400 Subject: [PATCH 2/3] VS: Fix default target support for targets nested inside a folder --- Source/cmGlobalVisualStudio71Generator.cxx | 5 - Tests/RunCMake/VSSolution/RunCMakeTest.cmake | 1 + Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake | 9 + Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake | 2 ++ 4 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 Tests/RunCMake/VSSolution/StartupProjectUseFolders-check.cmake create mode 100644 Tests/RunCMake/VSSolution/StartupProjectUseFolders.cmake diff --git a/Source/cmGlobalVisualStudio71Generator.cxx b/Source/cmGlobalVisualStudio71Generator.cxx index f6796a5..289fbb5 100644 --- a/Source/cmGlobalVisualStudio71Generator.cxx +++ b/Source/cmGlobalVisualStudio71Generator.cxx @@ -97,7 +97,8 @@ void cmGlobalVisualStudio71Generator OrderedTargetDependSet orderedProjectTargets( projectTargets, this->GetStartupProjectName(root)); -
[cmake-developers] FW: 15975 Bug Fix GHS MULTI try compile
Thank you. The patch seems to solve the problem (15975) for me. I saw the patch was committed on the "next" branch. How does the further procedure look like until it becomes part of an official CMake release and how long does that take usually? Regards, Stefan -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Brad King Sent: Montag, 21. März 2016 15:40 To: Geoffrey Viola; cmake-developers@cmake.org Subject: Re: [cmake-developers] 15975 Bug Fix GHS MULTI try compile On 03/21/2016 07:28 AM, Geoffrey Viola wrote: > Attached are updates for the bug recorded at > https://cmake.org/Bug/view.php?id=15975. Thanks, applied: GHS: Fix try_compile https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf3e76d2 -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 -- 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] 15975 Bug Fix GHS MULTI try compile
On 03/21/2016 07:28 AM, Geoffrey Viola wrote: > Attached are updates for the bug recorded at > https://cmake.org/Bug/view.php?id=15975. Thanks, applied: GHS: Fix try_compile https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf3e76d2 -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] Contribution for Issue #0015146
On 03/19/2016 06:56 AM, Sebastian Windisch wrote: > I like to contribute code for issue #0015146. Thanks! > What I did: I introduced a new flag in cmIDEFlagTable.h called > RegularExpression Good idea. That should be able to handle the special parsing mentioned in my comment in that issue: https://cmake.org/Bug/view.php?id=15146#c36772 > {"UACUIAccess", "MANIFESTUAC:level=([a-zA-Z]+) uiAccess=([a-zA-Z]+)$", > "", "\\2", cmVS7FlagTable::RegularExpression}, This does not look sufficient to match the example given in the issue description: -MANIFESTUAC:"level='requireAdministrator' uiAccess='false'" IIUC the single quotes are optional as they appear to work when passed directly on a command line build. Also I suspect more whitespace needs to be tolerated. There are some existing UACExecutionLevel entries in the link flag tables that were produced by the automated tool we use to generate the flag tables from MSBuild files originally. Please check that they can be removed in favor of your new entries. Thanks, -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] more use of cmXMLWriter
On 03/19/2016 05:08 PM, Daniel Pfeifer wrote: > I ported some more generators to cmXMLWriter. Thanks. I've applied and merged to 'next' for testing: cmXMLWriter: overload Element() method for empty elements https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd27e313 cmXMLWriter: add Doctype() method https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7407621 cmExtraCodeBlocksGenerator: port to cmXMLWriter https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27e09764 cmExtraCodeLiteGenerator: port to cmXMLWriter https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dcdc270e cmGlobalKdevelopGenerator: port to cmXMLWriter https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfd8b4d3 cmExtraEclipseCDT4Generator: port to cmXMLWriter https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9908f705 CPack/IFW: port to cmXMLWriter https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8356001 -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
[cmake-developers] 15975 Bug Fix GHS MULTI try compile
Attached are updates for the bug recorded at https://cmake.org/Bug/view.php?id=15975. The updates make the Green Hills MULTI executable suffix, .as, set in the CMAKE_EXECUTABLE_SUFFIX macro, instead of in the C++ code where it wasn't accessible to the other parts of CMake. As a side note, both Green Hills and Linux do not have suffixes on their executables by default. The .as suffix is somewhat arbitrary. A CMAKE_EXECUTABLE_SUFFIX value of "" will not work because Green Hills MULTI does not allow for filenames and folders in the same directory. At try_compile's the compilation stage, there will be a folder named after the project name for the project at the root. Since the RUNTIME_OUTPUT_DIRECTORY is set to the root, the compilation will stop and explain that the output file is a directory. This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 0001-15975-fix-for-GHS-MULTI-try_compile.patch Description: 0001-15975-fix-for-GHS-MULTI-try_compile.patch -- 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] C# support ready for review
Uhm, I have to admit that I have not experience in unity development at all so this is not that much of a simple question for me. But my main motivation for native C# support in CMake was to be able to mix native C++, managed C++ and C# binaries within one solution and to build them all together. If this is what you would like to do: yes this works well for me. best regards, Michael > -Original Message- > From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] > On Behalf Of Jean-Michaël Celerier > Sent: Monday, March 21, 2016 9:26 AM > To: Stuermer, Michael SP/HZA-ZSEP > Cc: CMake Developers > Subject: Re: [cmake-developers] C# support ready for review > > Simple question : do you think that this would be useable in order to have a > single build pipeline based on CMake for a Unity3D project that also requires > some native C++ libs ? > > Thanks ! > > > On Mon, Mar 21, 2016 at 8:09 AM, Stuermer, Michael SP/HZA-ZSEP >wrote: > > Sorry for asking, but do you mean > > > > 1. without support for ninja/nmake/make there is no use having C# > > support in cmake > > > > or > > > > 2. using the current approach this could also work with the other > > generators without too much additional work > > > > ? > > > > I'm just a little confused and try to find out what's on my todo list until > > C# > support may reach a mature level. > > > > best regards, > > Michael > > > >> -Original Message- > >> From: David Cole [mailto:dlrd...@aol.com] > >> Sent: Tuesday, March 08, 2016 12:51 AM > >> To: Brad King > >> Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > >> Subject: Re: [cmake-developers] C# support ready for review > >> > >> Seems to me like C# support should work just fine with other generators: > >> ninja, nmake, and UNIX Makefiles included. Especially with mono on > >> Linux/Mac. > >> > >> > >> David > >> > >> > On Mar 7, 2016, at 2:12 PM, Brad King wrote: > >> > > >> >> On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > >> >> The part that probably needs most additional work is all the C# > >> >> detection and configuration part in the module scripts. > >> > > >> > In your branch Modules/CMakeDetermineCSharpCompiler.cmake > >> currently > >> > has a lot of logic and environment checks for this. It shouldn't > >> > need to be that complicated. Anything requiring deep introspection > >> > of the system (especially the registry) should be something done in > >> > the C++ generator implementation and provided to CMake platform > >> > files as a variable. > >> > > >> > For example, the VS generators always provide msbuild: > >> > > >> > > >> > https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM > >> AND.ht > >> > ml > >> > > >> > For the path to the compiler tool, take a look at > >> > > >> > Modules/CompilerId/VS-10.vcxproj.in > >> > > >> > and use of it by Modules/CMakeDetermineCompilerId.cmake. That all > >> > runs while detecting the compiler id using a small test project. > >> > It has a custom command that searches the PATH in the IDE project > >> > build environment to print out the path to the compiler. You > >> > should create one like this for CSharp too. > >> > > >> > We'll also need to define behavior when CSharp is enabled by > >> > projects under a non-VS generator. Other generators should reject > >> > any such attempt with an error message. > >> > > >> > Thanks, > >> > -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 > > -- > > > > 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
Re: [cmake-developers] C# support ready for review
Simple question : do you think that this would be useable in order to have a single build pipeline based on CMake for a Unity3D project that also requires some native C++ libs ? Thanks ! On Mon, Mar 21, 2016 at 8:09 AM, Stuermer, Michael SP/HZA-ZSEPwrote: > Sorry for asking, but do you mean > > 1. without support for ninja/nmake/make there is no use having C# support in > cmake > > or > > 2. using the current approach this could also work with the other generators > without too much additional work > > ? > > I'm just a little confused and try to find out what's on my todo list until > C# support may reach a mature level. > > best regards, > Michael > >> -Original Message- >> From: David Cole [mailto:dlrd...@aol.com] >> Sent: Tuesday, March 08, 2016 12:51 AM >> To: Brad King >> Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers >> Subject: Re: [cmake-developers] C# support ready for review >> >> Seems to me like C# support should work just fine with other generators: >> ninja, nmake, and UNIX Makefiles included. Especially with mono on >> Linux/Mac. >> >> >> David >> >> > On Mar 7, 2016, at 2:12 PM, Brad King wrote: >> > >> >> On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: >> >> The part that probably needs most additional work is all the C# >> >> detection and configuration part in the module scripts. >> > >> > In your branch Modules/CMakeDetermineCSharpCompiler.cmake >> currently >> > has a lot of logic and environment checks for this. It shouldn't need >> > to be that complicated. Anything requiring deep introspection of the >> > system (especially the registry) should be something done in the C++ >> > generator implementation and provided to CMake platform files as a >> > variable. >> > >> > For example, the VS generators always provide msbuild: >> > >> > >> https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM >> AND.ht >> > ml >> > >> > For the path to the compiler tool, take a look at >> > >> > Modules/CompilerId/VS-10.vcxproj.in >> > >> > and use of it by Modules/CMakeDetermineCompilerId.cmake. That all >> > runs while detecting the compiler id using a small test project. >> > It has a custom command that searches the PATH in the IDE project >> > build environment to print out the path to the compiler. You should >> > create one like this for CSharp too. >> > >> > We'll also need to define behavior when CSharp is enabled by projects >> > under a non-VS generator. Other generators should reject any such >> > attempt with an error message. >> > >> > Thanks, >> > -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 > -- > > 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
Re: [cmake-developers] C# support ready for review
Sorry for asking, but do you mean 1. without support for ninja/nmake/make there is no use having C# support in cmake or 2. using the current approach this could also work with the other generators without too much additional work ? I'm just a little confused and try to find out what's on my todo list until C# support may reach a mature level. best regards, Michael > -Original Message- > From: David Cole [mailto:dlrd...@aol.com] > Sent: Tuesday, March 08, 2016 12:51 AM > To: Brad King > Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] C# support ready for review > > Seems to me like C# support should work just fine with other generators: > ninja, nmake, and UNIX Makefiles included. Especially with mono on > Linux/Mac. > > > David > > > On Mar 7, 2016, at 2:12 PM, Brad Kingwrote: > > > >> On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > >> The part that probably needs most additional work is all the C# > >> detection and configuration part in the module scripts. > > > > In your branch Modules/CMakeDetermineCSharpCompiler.cmake > currently > > has a lot of logic and environment checks for this. It shouldn't need > > to be that complicated. Anything requiring deep introspection of the > > system (especially the registry) should be something done in the C++ > > generator implementation and provided to CMake platform files as a > > variable. > > > > For example, the VS generators always provide msbuild: > > > > > https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM > AND.ht > > ml > > > > For the path to the compiler tool, take a look at > > > > Modules/CompilerId/VS-10.vcxproj.in > > > > and use of it by Modules/CMakeDetermineCompilerId.cmake. That all > > runs while detecting the compiler id using a small test project. > > It has a custom command that searches the PATH in the IDE project > > build environment to print out the path to the compiler. You should > > create one like this for CSharp too. > > > > We'll also need to define behavior when CSharp is enabled by projects > > under a non-VS generator. Other generators should reject any such > > attempt with an error message. > > > > Thanks, > > -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 -- 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] C# support ready for review
Thanks for the hints, I will adapt the C# detection. best regards, Michael > -Original Message- > From: Brad King [mailto:brad.k...@kitware.com] > Sent: Monday, March 07, 2016 8:12 PM > To: Stuermer, Michael SP/HZA-ZSEP > Cc: Gilles Khouzam; CMake Developers > Subject: Re: [cmake-developers] C# support ready for review > > On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > The part that probably needs most additional work is all the C# > > detection and configuration part in the module scripts. > > In your branch Modules/CMakeDetermineCSharpCompiler.cmake currently > has a lot of logic and environment checks for this. It shouldn't need to be > that complicated. Anything requiring deep introspection of the system > (especially the registry) should be something done in the C++ generator > implementation and provided to CMake platform files as a variable. > > For example, the VS generators always provide msbuild: > > > https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM > AND.html > > For the path to the compiler tool, take a look at > > Modules/CompilerId/VS-10.vcxproj.in > > and use of it by Modules/CMakeDetermineCompilerId.cmake. That all runs > while detecting the compiler id using a small test project. > It has a custom command that searches the PATH in the IDE project build > environment to print out the path to the compiler. You should create one > like this for CSharp too. > > We'll also need to define behavior when CSharp is enabled by projects under > a non-VS generator. Other generators should reject any such attempt with > an error message. > > Thanks, > -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