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

[Gilles Khouzam]

Hi Michael,

Great work, this looks really good.

I have a few comments on the changes.


1.   You should use the registry to find the install path for MSBuild, it 
should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the 
version that you're looking for. This also bring the question of do you want to 
be able to specify the version of MSBuild that is used or base it off the 
generator?

2.   In CMakeTestCSharpCompiler, you seem to still have a reference to your 
specific user path (COPY_FILE 
"C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp"))

You seem to have some slight discrepancies between your code and the release as 
there are changes that seem to be either unnecessary or going backwards. I 
noticed a tegra comment that seemed out of place as well as a comment change 
going from 14 to 12 where 14 was accurate.

I'll try to play with this next week and get projects running on it.

~Gilles

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Stuermer, Michael SP/HZA-ZSEP
Sent: Wednesday, February 10, 2016 06:03
To: CMake Developers 
Subject: [cmake-developers] C# support ready for review

Native C# support is ready for review. I split the patch in two parts:

part 1:

Some preparational stuff that does not really change or enable anything. 
Documentation and Test files as well as the required CMake module is added. The 
changes to existing code are small, only few methods in existing classes are 
added/changed. Changes to existing code should be easy to review in this part

part 2:

This contains the main work. Almost everything takes place within 
cmVisualStudio10TargetGenerator.


In addition to C# support three more target properties were introduced:

*   VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in 
.vcxproj files)
*   VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in 
.csproj files)
*   VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working 
directory in .vcxproj files)

I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything 
works on my machine so far.

Please review/test/comment and give feedback what is necessary to get native C# 
support in upstream cmake.

best regards,
Michael


-- 

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] [Qt-creator] CMake daemon for user tools

[Milian Wolff]

On Mittwoch, 17. Februar 2016 22:59:36 CET Stephen Kelly wrote:
> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> > Hi Dominik,
> > 
> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"  > 
> > >:
> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
> > 
> > I'd be in, but I do not have the time to organize one. I could
> > probably get a room in our office though (in Berlin).
> 
> I'd be up for a sprint in Berlin too, but given the muted response so
> far here, it's not clear who would want to join and what we could achieve.

Considering the three of us (Tobias, you and me) are in Berlin, I'd say we at 
least meet for a hackday or so. What do you say? That would get me at least to 
work 8h on this for a full day and see how it integrates with KDevelop and we 
could discuss things in-person. Still, I'm aware that I'll have to play around 
with it before already to not waste too much of your time.

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

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-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS

[Daniel Wirtz]

hey,

unfortunately i wont have the time to go dig in and provide a test for 
that .. my work on this project literally ends
in one week. we've got our own fork of cmake 
(https://github.com/OpenCMISS-Dependencies/CMake) that contains fix.


here's a patch (based on current master 
ed1b3430fcfc906780b68fe4a073590c6d23ff08) that at least gets this going.
i believe if no one yet complained about the missing feature, it may as 
well stay as "unsupported" as its been before - at least then the
current project group would not have to maintain an extra CMake fork and 
build process just for those two lines :-)


---

From 480a359e795d59d9176251f9d98dbadffafd9793 Mon Sep 17 00:00:00 2001
From: Daniel Wirtz 
Date: Thu, 18 Feb 2016 11:30:05 +1300
Subject: [PATCH]  Fixed the ignored SubDirectory directive for CPack using
 CPACK_INSTALL_CMAKE_PROJECTS

---
 Source/CPack/cmCPackGenerator.cxx | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Source/CPack/cmCPackGenerator.cxx 
b/Source/CPack/cmCPackGenerator.cxx

index 22d4bf0..3eca280 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -723,10 +723,9 @@ int 
cmCPackGenerator::InstallProjectViaInstallCMakeProjects(

 cmGlobalGenerator gg();
 cmsys::auto_ptr mf(
   new cmMakefile(, cm.GetCurrentSnapshot()));
-std::string realInstallDirectory = tempInstallDirectory;
 if ( !installSubDirectory.empty() && installSubDirectory != "/" )
   {
-  realInstallDirectory += installSubDirectory;
+  tempInstallDirectory += installSubDirectory;
   }
 if (componentInstall)
   {
--
2.7.0.windows.1


On 18.02.2016 04:56, Brad King wrote:

On 02/16/2016 03:46 PM, Daniel Wirtz wrote:

i think i've encountered a bug where the fourth (=SubDirectory) entry of
the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored.

[snip]

The offending lines of code have been committed in 2006 with
c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever
tried to use something other than "/" since then?

That appears to be the case.  There is no test case in our test suite
for it either.  If you fix this please look at adding one.  Also update
the documentation to clarify the use case.

Thanks,
-Brad



--
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a, D-70569 Stuttgart
+49 (711) 685-60044

--

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] CMake Daemon blog

[Stephen Kelly]

Taylor Braun-Jones wrote:

> On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly
>  wrote:
>> I've just pushed the daemon code here:
>>
>>  https://github.com/steveire/cmake/tree/cmake-daemon
>>
>> The Kate plugin should soon appear here I think:
>>
>>  https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git
> 
> Thanks for sharing, Stephen! Do you plan to also share the standalone
> Qt-based editor/client as well (cmake-browser)? That would be
> immediately useful to me and allow me to more easily test drive all
> this work that you've done.

I've deliberately not pushed that yet because it would put the wrong focus 
on the conversation:

* It doesn't need a test drive because I know it is limited by the daemon
* The focus needs to be on the implementation of the daemon first to make 
that work better. That can be done by anyone determined enough to paste some 
things into the stdin. 

For more see

 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15741

Thanks,

Steve.


-- 

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] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

On 02/15/2016 07:24 PM, Tobias Hunger wrote:
>
> Hi Dominik,
>
> Am 15.02.2016 19:01 schrieb "Dominik Haumann"  >:
> > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
>
> I'd be in, but I do not have the time to organize one. I could
> probably get a room in our office though (in Berlin).
>

I'd be up for a sprint in Berlin too, but given the muted response so
far here, it's not clear who would want to join and what we could achieve.

Thanks,

Steve.

-- 

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] [PATCH]: CodeBlocks: improve support for different compilers

[Alexander Neundorf]

On Tuesday, February 16, 2016 10:49:24 Brad King wrote:
> On 02/12/2016 03:24 AM, melven.roehrig-zoell...@dlr.de wrote:
> > Just a small patch for the CodeBlocks generator
> 
> Thanks!  Applied:
> 
>  CodeBlocks: improve support for different compilers
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=184da3f4

Thanks :-)
Alex

-- 

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] FindCUDA.cmake regression in 3.5.0-rc2

[Sorley, Stephen L.]

I tested your fix, it's working well for my project.  Thanks for the quick 
response!

-Stephen S.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, February 17, 2016 3:28 PM
To: Sorley, Stephen L.
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote:
> FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution 
> files for Visual Studio on Windows (VS 2013 update 4, to be specific).  
> The ninja generator on Windows is unaffected.

Thanks for trying the release candidate and tracking this down!

In the long run I agree that switching away from $(VCInstallDir) is best, but 
it is mentioned in several other places within the module and is documented as 
a valid user-provided value.  For now I'd like to fix the regression with 
minimal changes.

Please test this fix on top of 3.5.0-rc2:

 FindCUDA: Fix regression under Visual Studio generators
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda0

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] FindCUDA.cmake regression in 3.5.0-rc2

[Brad King]

On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote:
> FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating
> solution files for Visual Studio on Windows (VS 2013 update 4,
> to be specific).  The ninja generator on Windows is unaffected.

Thanks for trying the release candidate and tracking this down!

In the long run I agree that switching away from $(VCInstallDir)
is best, but it is mentioned in several other places within the
module and is documented as a valid user-provided value.  For
now I'd like to fix the regression with minimal changes.

Please test this fix on top of 3.5.0-rc2:

 FindCUDA: Fix regression under Visual Studio generators
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda0

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

[cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

[Sorley, Stephen L.]

FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution files 
for Visual Studio on Windows (VS 2013 update 4, to be specific).  The ninja 
generator on Windows is unaffected.

When I attempt to build a cuda target, the compile step for each .cu file fails 
with the following message:

Building NVCC (Device) object 
utils/CMakeFiles/utils_cu.dir/Release/utils_cu_generated_cudaarray.cu.obj
3>  cudaarray.cu
3>
3>  '$' is not recognized as an internal or external command,
3>
3>  operable program or batch file.
3>
3>  CMake Error at utils_cu_generated_cudaarray.cu.obj.cmake:207 (message):
3>Error generating
3>
C:/Users/sorlesl1/Desktop/testproj/build/utils/CMakeFiles/utils_cu.dir//Release/utils_cu_generated_cudaarray.cu.obj

I've traced the problem to this 
commit,
 which added VERBATIM to the add_custom_command() call in CUDA_WRAP_SRCS.

Adding the VERBATIM flag changes how the escaped double-quotes in the 
ccbin_flags variable are interpreted:

Without verbatim, ${ccbin_flags} expands to the following in the generated VS 
project:
   -D "CCBIN:PATH=$(VCInstallDir)bin"

With verbatim, the double quotes are escaped in the generated project, causing 
the error:
   -D \"CCBIN:PATH=$(VCInstallDir)bin\"

If the escaped quotes are omitted entirely when ccbin_flags is set, the custom 
command still fails, this time due to VCInstallDir expanding at compile time to 
a path containing spaces.

According to bug 15001, there isn't 
any way in CMake to correctly quote Visual Studio placeholder variables that 
expand to values containing spaces - you'll always get either no quotes, or 
escaped quotes.  However, I was able to work around this problem by getting the 
compiler path directly from CMake instead of using the placeholder.  Please see 
the attached patch (it's based on master) - with this patch, compiling CUDA 
code with Visual Studio works again.

Thanks,
Stephen Sorley


0001-Fixed-Visual-Studio-CUDA-compile-failure.patch
Description: 0001-Fixed-Visual-Studio-CUDA-compile-failure.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] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[James Crosby]

> On 17 Feb 2016, at 14:33, Brad King  wrote:
>
> One could look at adding hooks to the compiler id logic to add alternatives
> provided by the toolchain file.  Or, we could provide a way to set the 
> compiler
> id but not also skip other checks.  In the worst case such a company could 
> modify
> their CMake for use with such a toolchain.  I do not consider this a blocking
> issue for deprecating CMakeForceCompiler.

I think allowing the compiler id to be set might be enough – in the case that
the compiler is completely unknown, functionality is anyway going to be limited
to what the user implements/supports themselves.


> It is not just a check that linking works.  CMake actually encodes string
> literals in the compiled binary and parses it to extract them.  This allows
> us to extract information about the compiler target architecture and compiler
> capabilities.  OTOH we may not actually have to link to achieve this.
>
> Perhaps we could have a setting in a toolchain file like
>
>set(CMAKE_TRY_COMPILE_NO_LINK 1)
>
> that tells CMake to use add_library(STATIC) instead of add_executable()
> in its generated try_compile projects.  That would avoid linking through
> the toolchain.

OK this makes a lot more sense to me now (I should have looked at the code
first ;). It seems like the option to link a static library would have all the
benefits of getting information out of the compiler itself (instead of
duplicating it in toolchain files), without having to be able to produce a
linkable executable.


> Meanwhile I've de-deprecated the module for the 3.5 release:

Thanks, this will be useful breathing space!


James

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-- 

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] [CMake 0015978]: Visual Studio 2015 Update 2 CTP support

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15978 
== 
Reported By:Niclas Larsén
Assigned To:
== 
Project:CMake
Issue ID:   15978
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   high
Status: new
== 
Date Submitted: 2016-02-17 11:06 EST
Last Modified:  2016-02-17 11:06 EST
== 
Summary:Visual Studio 2015 Update 2 CTP support
Description: 
the latest visual studio preview isn't supported by cmake.

-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:43 (project):
  No CMAKE_C_COMPILER could be found.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-17 11:06 Niclas Larsén  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] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS

[Brad King]

On 02/16/2016 03:46 PM, Daniel Wirtz wrote:
> i think i've encountered a bug where the fourth (=SubDirectory) entry of 
> the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored.
[snip]
> The offending lines of code have been committed in 2006 with 
> c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever 
> tried to use something other than "/" since then?

That appears to be the case.  There is no test case in our test suite
for it either.  If you fix this please look at adding one.  Also update
the documentation to clarify the use case.

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] Pssible documentation error in install(TARGETS ) signature

[Brad King]

On 02/16/2016 05:42 PM, Daniel Wirtz wrote:
> if the order of the arguments matters: update documentation?

Thanks, updated:

 Help: Clarify install(TARGETS) INCLUDES DESTINATION option
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c978223c

-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] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Brad King]

On 02/16/2016 04:15 PM, Simon Richter wrote:
> Hm, only problem is patch attribution here -- I've written that these
> are from Wayne, and should be attributed to him (but submitting these
> with his name in the From: field obviously would not have worked).

IIRC if you commit with --author='...' then `git format-patch` adds info
to the message that records the author even when you send the email.

> Can this still be fixed?

Yes, the patch had only been merged to 'next' for testing.  Here is a
revised version which will become the one merged to 'master':

 FindwxWidgets: Resolve Cygwin/MSYS paths to Windows paths
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf643286

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] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[Brad King]

Moving discussion to cmake-developers.

On 02/15/2016 12:47 PM, James Crosby wrote:
> I'm worried that built-in compiler detection might not be possible across
> the variety of cross-compilers used. In some cases, for example, the
> existence of a particular compiler, or a modified version of it, might be
> a secret outside of the company using it.

One could look at adding hooks to the compiler id logic to add alternatives
provided by the toolchain file.  Or, we could provide a way to set the compiler
id but not also skip other checks.  In the worst case such a company could 
modify
their CMake for use with such a toolchain.  I do not consider this a blocking
issue for deprecating CMakeForceCompiler.

> Using a dummy link command to check that linking works seems to
> undermine the purpose of checking in the first place, which suggests
> that perhaps it should still be possible to skip the check?

It is not just a check that linking works.  CMake actually encodes string
literals in the compiled binary and parses it to extract them.  This allows
us to extract information about the compiler target architecture and compiler
capabilities.  OTOH we may not actually have to link to achieve this.

Perhaps we could have a setting in a toolchain file like

set(CMAKE_TRY_COMPILE_NO_LINK 1)

that tells CMake to use add_library(STATIC) instead of add_executable()
in its generated try_compile projects.  That would avoid linking through
the toolchain.

Meanwhile I've de-deprecated the module for the 3.5 release:

 CMakeForceCompiler: De-deprecate until more use cases have alternatives
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=beaa4fa5

However, I'd really like to get a solution to the above worked out so
that it can be re-deprecated for the 3.6 release.  The module is simply
not compatible with all the information CMake now wants to detect from
toolchains.

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] Run program/command before test

[Roman Wüger]

Hi Nils,

great thanks.

Regards
Roman 

> Am 17.02.2016 um 09:09 schrieb Nils Gladitz :
> 
>> On 17.02.2016 07:58, Roman Wüger wrote:
>> Ok thanks
>> 
>> Would it be an opinion to have a COMMAND parameter for the add_test function 
>> like execute_process where every COMMAND must return the exit code and this 
>> would be ored?
>> 
>> add_test(MyTest COMMAND myserver --port 80
>>   COMMAND mytest
>>   COMMAND myserver --graceful-shutdown)
>> 
>> Or
>> 
>> add_test(MyTest PRE_COMMAND myserver --port 80
>>   COMMAND mytest
>>   POST_COMMAND myserver --graceful-shutdown)
> 
> What you could already do is wrap your test in a cmake script.
> 
> E.g.
> 
>add_test(NAME MyTest
>COMMAND ${CMAKE_COMMAND} -DACTUAL_TEST=$ -P 
> ${CMAKE_CURRENT_SOURCE_DIR}/mywrapper.cmake
>)
> 
> Where mywrapper.cmake could do something like:
> 
>execute_process(COMMAND mysever --port 80 ...)
> 
>execute_process(COMMAND ${ACTUAL_TEST} )
> 
>execute_process(COMMAND mysever --graceful-shutdown)
> 
> To have the test fail you could call message(FATAL_ERROR "...")
> 
> For this to work myserver would have to daemonize/fork (but I assume that is 
> the case given your example).
> 
> Nils
-- 

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] Run program/command before test

[Nils Gladitz]

On 17.02.2016 07:58, Roman Wüger wrote:

Ok thanks

Would it be an opinion to have a COMMAND parameter for the add_test function 
like execute_process where every COMMAND must return the exit code and this 
would be ored?

add_test(MyTest COMMAND myserver --port 80
   COMMAND mytest
   COMMAND myserver --graceful-shutdown)

Or

add_test(MyTest PRE_COMMAND myserver --port 80
   COMMAND mytest
   POST_COMMAND myserver --graceful-shutdown)


What you could already do is wrap your test in a cmake script.

E.g.

add_test(NAME MyTest
COMMAND ${CMAKE_COMMAND} -DACTUAL_TEST=$ -P 
${CMAKE_CURRENT_SOURCE_DIR}/mywrapper.cmake

)

Where mywrapper.cmake could do something like:

execute_process(COMMAND mysever --port 80 ...)

execute_process(COMMAND ${ACTUAL_TEST} )

execute_process(COMMAND mysever --graceful-shutdown)

To have the test fail you could call message(FATAL_ERROR "...")

For this to work myserver would have to daemonize/fork (but I assume 
that is the case given your example).


Nils
--

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