[cmake-developers] [CMake 0016027]: nvcc encloses -ccbin argument with gratuitous quotation marks during intermediate-link phase

2016-03-21 Thread Mantis Bug Tracker

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]

2016-03-21 Thread Taylor Braun-Jones
On Fri, Mar 18, 2016 at 1:31 PM, Brad King  wrote:
>
> 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

2016-03-21 Thread Wurzinger, Stefan
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

2016-03-21 Thread Brad King
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

2016-03-21 Thread Brad King
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

2016-03-21 Thread Brad King
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

2016-03-21 Thread Geoffrey Viola
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

2016-03-21 Thread Stuermer, Michael SP/HZA-ZSEP
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

2016-03-21 Thread Jean-Michaël Celerier
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 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

2016-03-21 Thread Stuermer, Michael SP/HZA-ZSEP
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


Re: [cmake-developers] C# support ready for review

2016-03-21 Thread Stuermer, Michael SP/HZA-ZSEP
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