[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:

Re: [cmake-developers] Startup Project Configuration [mantis 15578]

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

[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-

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

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:

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()

[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

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

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: >

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

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: