Re: [cmake-developers] C# support ready for review
Hi Michael, I've had more time to try this, what is the reasoning to hardcode the default LangVersion to 3 in Modules\CMakeCSharpInformation.cmake? Can we remove it? I'm trying this on some projects of mine. From: Stuermer, Michael SP/HZA-ZSEP [mailto:michael.stuer...@schaeffler.com] Sent: Thursday, February 18, 2016 03:44 To: Gilles Khouzam ; CMake Developers Subject: RE: C# support ready for review Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:gilles.khou...@microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review 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 mailto:cmake-developers@cmake.org>> 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] CMakeFindDependencyMacro limitations
On 24/12/2015 12:07, Stephen Kelly wrote:
Roger Leigh wrote:
On 21/12/2015 15:07, Stephen Kelly wrote:
Roger Leigh wrote:
I can understand why REQUIRED and related
arguments are omitted--that is why find_dependency exists--but I'd quite
like to be able to specify COMPONENTS where needed e.g. with FindBoost,
and this is not currently possible.
I don't remember whether this was discussed when designing
find_dependency. Perhaps COMPONENTS could be added to the macro now.
Currently, for my own needs, COMPONENTS is the single missing piece. If
it would be possible to add this, it would certainly be very useful.
I'd be happy to provide a patch for COMPONENTS if you like.
I think the reason that the macro does not support COMPONENTS is that I
don't understand how COMPONENTS is supposed to work. For example:
find_package(Qt5 COMPONENTS Widgets)
# Is Qt5_FOUND set to true or false?
find_package(Qt5 COMPONENTS Quick)
# ... what about now?
What does _FOUND ever mean if the find_package is called multiple
times with different components? Does it mean anything?
I would think that it would mean whether the last call succeeded or
failed for the requested components at that time. It wouldn't have any
greater or more permanent meaning. To the best of my knowledge, that's
what the status quo is for find_package.
Should CMake disallow multiple use of find_package with the same package and
with different components?
If user code has
find_package(Qt5 COMPONENTS Widgets)
find_package(FooBar REQUIRED)
and FooBarConfig.cmake has
find_dependency(Qt5 COMPONENTS Quick)
then the if(Qt5_FOUND) in the macro will mean it will not try to find the
Quick component.
So, there may be a need to establish a convention such as
__FOUND
and check that for each component in the macro.
Right now, it's certainly possible for this to happen. I'm seeing this
myself with multiple packages (or individual components' config scripts)
requiring different sets of Boost components. Each invokes
find_dependency with its own needed set of components.
You would also need to think through everything and find out whether that is
really a full solution. I haven't thought more deeply about it than the
above.
Note that the above example with Qt 5 can not currently happen in practice
because the find_dependency macro does not support COMPONENTS, so config
files must instead use
find_dependency(Qt5Quick)
if they want to use the macro currently. This is a good thing.
So, I would like to know if
* adding COMPONENTS support to the find_dependency macro is the right thing
to do
* or if the right thing to do is to move away from support for COMPONENTS
generally because of its messy semantics
* or if find_package should change to not support multiple calls for the
same package.
I really don't know the answer - I think someone needs to do deep thinking
about it.
I would prefer the macro not be changed before that deep thinking about
COMPONENTS generally is done.
I've attached a patch for a very simple modification to find_dependency.
I'm not proposing that it be merged, it's just a suggestion for
further discussion. I've tested it with my own packages with multiple
find_dependency(Boost COMPONENTS ...) calls. Some rationale and
thoughts follow:
Regarding the messy semantics of find_package, I agree it's not ideal.
However, I find the differing behaviour of find_dependency and
find_package even less so. Ideally I should be able to call both
multiple times, or neither. While as you mentioned for Qt5, it's
possible to work around this by calling find_dependency for each
component by hand, but that's not possible for all packages. Boost for
example does not work this way, making this a major blocker to using
find_dependency with Boost. I'm basically blocked by this right now,
and the patch here removes the single call restriction and passes
through COMPONENTS, making it work. That would at the very least make
things consistent and functional.
I don't think it's in general going to be possible to avoid multiple
calls. Complex projects including or depending upon other projects are
going to do this inevitably, and they may have differing version
requirements as well as different sets of components. And it's already
in established use. I don't think for find_dependency that returning
immediately if ${dep}_FOUND is true is correct behaviour--it skips the
version check, and I think it should be calling find_package to do this
check under all circumstances. I think it's trading correctness for
speed, but I really would prefer to have the version check performed
correctly every time.
Regarding having __FOUND, I think this would be
useful irrespective of any find_dependency changes. And coupled with
the above patch, find_dependency could be extended to return immediately
if the version check is satisfied *and* all the requested components are
found (if specifie
[cmake-developers] [CMake 0015986]: Visual Studio 2015 does not work with v120 toolset
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15986 == Reported By:Gregor Jasny Assigned To: == Project:CMake Issue ID: 15986 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2016-02-24 11:24 EST Last Modified: 2016-02-24 11:24 EST == Summary:Visual Studio 2015 does not work with v120 toolset Description: Hello, today I tried to use Visual Studio 2015 to build with the VS2013 (v120) toolset. Unfortunately I get the following error: -- The C compiler identification is MSVC 18.0.40629.0 -- The CXX compiler identification is MSVC 18.0.40629.0 -- Check for working C compiler using: Visual Studio 14 2015 -- Check for working C compiler using: Visual Studio 14 2015 -- broken CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe" is not able to compile a simple test program. It properly works in the "same" toolchain pairing: -G "Visual Studio 12 2013" -T v120 -G "Visual Studio 14 2015" -T v140 Thanks, Gregor Steps to Reproduce: CMakeLists.txt containing just: project(VS2015Test C CXX) Configure: "c:\Program Files (x86)\CMake\bin\cmake.exe" -G "Visual Studio 14 2015" -T v120 .. Additional Information: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(639,9): error MSB4030: "Debug" is an invalid value for the "GenerateDebugInformation" parameter of the "Link" task. The "GenerateDebugInformation" parameter is of type "System.Boolean". [C:\Users\gregorj\devtrees\vs2015test\_build\CMakeFiles\CMakeTmp\cmTC_05d1a.vcxproj] == Issue History Date ModifiedUsername FieldChange == 2016-02-24 11:24 Gregor Jasny New Issue 2016-02-24 11:24 Gregor Jasny File Added: CMakeError.log == -- 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] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator
On 02/22/2016 11:35 AM, fabian.o...@rohde-schwarz.com wrote: > The patch adds the target property VS_CONFIGURATION_TYPE. It allows to > set an arbitrary value to the "ConfigurationType" property > > This is useful if you want to build a Windows Kernel Mode Driver. This looks okay to me. Please extend the test suite to cover this feature. So far all VS features that we test have effects on the generation that we can test explicitly. In this case it looks like we might not be able to test actually building such a project. For that, take a look at these test directories: Tests/RunCMake/SolutionGlobalSections Tests/RunCMake/XcodeProject It tests running CMake and then parses the actual project file content to check that it is as expected. A similar test could be added for VS .vcxproj content testing and used to cover this feature. 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] [PATCH v2] Now prints warning when --build is not honored
On 02/21/2016 10:16 AM, Ashley Whetter wrote: > In this version of the patch I've changed the message printed to give more > information on how '--build' should be used. What command line are you using to test this locally? Please also add a case to Tests/RunCMake/CommandLine for this. 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] [PATCH] Additional regression tests for cmake_parse_arguments
On 02/22/2016 05:16 AM, Yordanov, Dimitar wrote: > as requested please find attached some additional regression tests for > the cmake_parse_arguments implementation. Great, thanks! Applied: cmake_parse_arguments: Additional regression tests https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43025124 -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] Fixed some documentation typos
On 02/21/2016 10:17 AM, Ashley Whetter wrote: > --- > Help/manual/cmake-packages.7.rst | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Thanks, applied: Help: Fix typos in cmake-packages.7 manual https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=33507e2a -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
On 02/17/2016 01:46 PM, James Crosby wrote: >> Perhaps we could have a setting in a toolchain file like [snip] >> 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. Here is a change implementing this approach: try_compile: Add option to control type of target https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f1bd9fe One should be able to simply add set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) to the toolchain file. Then CMakeForceCompiler should not be needed anymore. Please try it out. 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] Unit Test App (Universal Windows)
Hello, does anyone successfully created a unit test for Windows 10 Universal? My current situation is that the unit tests are running if building for desktop. But if I try to build for winrt/universal/Windows 10 store then the tests aren't executed. When I create a unit test for Windows universal under visual studio then the tests are working. Thanks in advance Best regards Roman -- 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
