Re: [cmake-developers] Add command line options for deprecation message control
Michael Scott wrote: > Thanks for the comments, here is the previous patch, with the suggested > amendments. Thanks for working on this. I'm wondering how these new command line options relate to the existing options -Wdev and -Wno-dev. Is there any reason not to make those existing options set the CMAKE_WARN_DEPRECATED variable? What is the difference between the intended uses of those existing options and the intended uses of the new options, given that -Wno-dev is mostly useful for third parties to silence policy warnings? If the new options are merged to master should -Wdev and -Wno-dev also be changed to affect CMAKE_WARN_DEPRECATED? 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] C# support?
Michael, this is great. Thank you for doing this. I will gladly help with the other versions of Visual Studio and can provide some help if you need. Feel free to reach out. ~Gilles Khouzam -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Tuesday, June 30, 2015 00:22 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? Hi and thanks for all your answers, Let me give you some information how things are implemented so far and where my constraints in implementing C# support are: At the moment I have only Visual Studio 2013 available, which makes it hard for me to test any other generators. NMake is not a priority for me, but the concept of the Visual Studio generators in CMake is so nice implemented, that it should not be much of a problem to get this running. I will have a look on this once Visual Studio generators are working. I will be able to test some linux/mono functionality in VirtualBox, but I will most probably not have much time. We are working on Windows based software here and I will not be allowed to spent a vast amount of time working on non-project related topics. In short: it would be great if some people could step forward once everything is running from my side to help get makefile and linux support (and test other Visual Studio versions). About enable_language(): Working. From my knowledge it's mainly about have the appropriate cmake-scripts in "Module" directory. That's done, my test project builds well with it. Ok, the CMakeTest... script simply sets "WORKS" to true ... that could be improved ... About .csproj files: It's almost done, the files are generated already and working well. There still needs to be some cleaning and generalization to use parameters instead of hard coded information. About intrusiveness: Almost everything relevant goes in the target generator class VisualStudio10TargetGenerator. The necessary .cmake files for the language are added and some minor changes to other generator sources are needed (for setting target type GUID in .sln etc.). All changes so far are made to be as minimal as possible to the original cmake sources and I believe it blends in quite well. Credit goes to the guys who implemented the VisualStudio generator concept with the flagmaps. You need some time to understand it, but once you've got it it's really great. About C#/.NET: I'm new to .NET and C# as well, but it seems not to provide too many surprises. Nevertheless some challenges remain to come up with a good solution for C# integration. It's mainly about reference handling. I have a working example at the moment, but it could be improved further. About the language: Would it be ok to name the language in CMake "CS" instead of "CSharp"? I did everything as "CS" so far... About contributing: Once done, do you want patchfiles here on the list or a pull request from my fork on github? --- If someone is interested in the development so far, you can check out my CMake fork here (have a look at the "csharp" branch): https://github.com/micst/CMake.git The test project with mixed C++/C# targets, cross-referencing from C++ <--> managed C++ <--> C# can be found here: https://github.com/micst/CMakeCSharpTest.git best regards, Michael > -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On > Behalf Of David Cole via cmake-developers > Sent: Monday, June 29, 2015 7:31 PM > To: Brad King > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] C# support? > > The C# compiler, csc.exe, takes all its arguments at once in one call > to build a library or executable. Listing all the sources, and its > references (other libraries it depends on) all at once. You can do it > as command line arguments, or as contents of a response file, or a > combination or arguments plus response file. > > Conceptually, it's "just like Java." > > They do have separate project files for it with VS, though. The > generators will need code to generate *.csproj files, rather than > custom commands in a vcxproj file, to make it seem like it's really > well-integrated with VS. Not sure if *.csproj files have evolved much > over the last few releases of VS -- I'd expect the major challenge > with this to be making sure CMake generates proper *.csproj files for > however many versions of VS it would take to make it acceptable. > > > D > > > > On Mon, Jun 29, 2015 at 1:05 PM, Brad King > wrote: > > On 06/26/2015 10:47 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > >> Does it have a realistic chance to be accepted for upstream > > > > Yes, so long as it comes with proper tests and is not too intrusive > on > > the overall design/implementation of CMake. > > > > In order to enable use of C# sources we should get > > > > enable_language(CSharp) > > >
Re: [cmake-developers] C# support?
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Tuesday, June 30, 2015 13:49 > To: cmake-developers@cmake.org > Subject: Re: [cmake-developers] C# support? > > On 06/30/2015 03:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > it would be great if some people could step forward once everything is > > running from my side to help get makefile and linux support (and test > > other Visual Studio versions). > > Once you have it working in VS 2013 the other VS >= 2010 versions should be > easy. I'm not sure about other generators yet. If you have good coverage in > the test suite updates then that will make the task of adding support to other > generators easier. What about Visual Studio 2005 / 2008? In those scenarios: * The Visual C++ projects are NOT MSBuild projects (as the CMake devs I'm sure well know) * The Visual C# project *is* an MSBuild project. My guess is if targeting VS2005/2008, you'd need to somehow use code as follows: * The Visual C++ 2005/2008 projects generated as normal using VisualStudio8/9TargetGenerator classes. * The Visual C# 2005/2008 projects are MSBuild so you'd have to use the new code in VisualStudio10TargetGenerator when your CMake generator was set to "Visual Studio 8/9"? It sounds goofy... * And all the above projects put into one final VS2005/2008 solution file. Best regards, James Johnston -- 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] FindPython.cmake alternative for FindPythonInterp.cmake and FindPythonLibs.cmake
I just want to add that I also saw a colleague running in the issue described in the beginning of the thread and that the version reported by the Python module and the PythonLibs one were different strings, even though the version was actually the same. It happened on latest Debian I think. How I discovered it? I had a check in my CMakeLists.txt that ensured the strings were identical. It's the first time in years we saw it fail. /Florent On Tue, Jun 30, 2015 at 4:14 PM, Mark Moll wrote: > Brad, > > Thanks for the detailed explanation. I figured there were use cases not > handled by my module. For instance, I hadn’t thought of cross-compilation. > Since in my own project these unhandled cases haven't come up, I’ll stick > with own module for now. > > With the existing modules it might be useful to add a check that if both > PYTHON_VERSION_STRING and PYTHONLIBS_VERSION_STRING are defined, then they > should be equal. > > Best, > Mark > > > > > On Jun 30, 2015, at 9:02 AM, Brad King wrote: > > > > On 06/29/2015 09:41 PM, Mark Moll wrote: > >> I have attached an alternative module that replaces the two current > >> modules for finding python-related info. With the current modules > >> it is easy to end up in a situation where the interpreter’s version > >> and the library version do not match, which inevitably leads to > problems. > > > > Thanks for working on this. The need for a combined module has come > > up a few times. The main reason it has not been done is because > > designing a combined module that meets all the use cases of the > > current two modules and deals with Python 2 and 3 is likely very > > tricky. > > > > Overall my main concern is that no logic from the existing modules > > is used in the proposed module. The existing modules have worked > > for many projects for years and have a lot of knowledge built into > > them. If we combine FindPythonInterp and FindPythonLibs then the > > results should be similar to finding both packages individually. > > > > The combined module should check/validate COMPONENTS requested in the > > call to find_package. There could be Interp and Libs components such > > that the package can be found if one component is requested and the > > other is not available. > > > > When I've seen the need for a combined module discussed before, > > one issue that is commonly raised is that there should be separate > > FindPython2 and FindPython3 modules because the two languages are > > somewhat different and some projects may need to find both. Then > > there could also be a FindPython that accepts either version for > > projects that can support either. I'm not sure how variables should > > be named in each of the three modules, but their implementations > > should share as much code as possible. > > > > Further comments on the specific module implementation follow, > > though with the design requirements laid out above I doubt much > > of the code will be used as-is. I think this thread should first > > focus discussion on interface design and not work on the actual > > code yet. > > > > Thanks, > > -Brad > > > > > > - > > Currently the module depends on running the python executable. This > > can be allowed but cannot be required. The module must be able to > > work when cross-compiling where the libraries come with an executable > > that may not run on the host. > > > > Please read the cmake-developer(7) documentation on find modules: > > > > > http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#find-modules > > > > In particular please use the proper naming convention for cached > > v. result variables. Also the module documentation needs to have > > proper .rst formatting. > > > > The PYTHON_EXEC variable should be called PYTHON_EXECUTABLE. > > (This may change depending on the v2/v3 discussion above.) > > > > For find_python_module, please provide documentation of the function > > using the .rst markup and ".. command::" directive. Also please look > > at using CMakeParseArguments rather than custom ARGC testing. > > - > > -- > > > > 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: >
Re: [cmake-developers] FindPython.cmake alternative for FindPythonInterp.cmake and FindPythonLibs.cmake
Brad, Thanks for the detailed explanation. I figured there were use cases not handled by my module. For instance, I hadn’t thought of cross-compilation. Since in my own project these unhandled cases haven't come up, I’ll stick with own module for now. With the existing modules it might be useful to add a check that if both PYTHON_VERSION_STRING and PYTHONLIBS_VERSION_STRING are defined, then they should be equal. Best, Mark > On Jun 30, 2015, at 9:02 AM, Brad King wrote: > > On 06/29/2015 09:41 PM, Mark Moll wrote: >> I have attached an alternative module that replaces the two current >> modules for finding python-related info. With the current modules >> it is easy to end up in a situation where the interpreter’s version >> and the library version do not match, which inevitably leads to problems. > > Thanks for working on this. The need for a combined module has come > up a few times. The main reason it has not been done is because > designing a combined module that meets all the use cases of the > current two modules and deals with Python 2 and 3 is likely very > tricky. > > Overall my main concern is that no logic from the existing modules > is used in the proposed module. The existing modules have worked > for many projects for years and have a lot of knowledge built into > them. If we combine FindPythonInterp and FindPythonLibs then the > results should be similar to finding both packages individually. > > The combined module should check/validate COMPONENTS requested in the > call to find_package. There could be Interp and Libs components such > that the package can be found if one component is requested and the > other is not available. > > When I've seen the need for a combined module discussed before, > one issue that is commonly raised is that there should be separate > FindPython2 and FindPython3 modules because the two languages are > somewhat different and some projects may need to find both. Then > there could also be a FindPython that accepts either version for > projects that can support either. I'm not sure how variables should > be named in each of the three modules, but their implementations > should share as much code as possible. > > Further comments on the specific module implementation follow, > though with the design requirements laid out above I doubt much > of the code will be used as-is. I think this thread should first > focus discussion on interface design and not work on the actual > code yet. > > Thanks, > -Brad > > > - > Currently the module depends on running the python executable. This > can be allowed but cannot be required. The module must be able to > work when cross-compiling where the libraries come with an executable > that may not run on the host. > > Please read the cmake-developer(7) documentation on find modules: > > http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#find-modules > > In particular please use the proper naming convention for cached > v. result variables. Also the module documentation needs to have > proper .rst formatting. > > The PYTHON_EXEC variable should be called PYTHON_EXECUTABLE. > (This may change depending on the v2/v3 discussion above.) > > For find_python_module, please provide documentation of the function > using the .rst markup and ".. command::" directive. Also please look > at using CMakeParseArguments rather than custom ARGC testing. > - > -- > > 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] FindPython.cmake alternative for FindPythonInterp.cmake and FindPythonLibs.cmake
On 06/29/2015 09:41 PM, Mark Moll wrote: > I have attached an alternative module that replaces the two current > modules for finding python-related info. With the current modules > it is easy to end up in a situation where the interpreter’s version > and the library version do not match, which inevitably leads to problems. Thanks for working on this. The need for a combined module has come up a few times. The main reason it has not been done is because designing a combined module that meets all the use cases of the current two modules and deals with Python 2 and 3 is likely very tricky. Overall my main concern is that no logic from the existing modules is used in the proposed module. The existing modules have worked for many projects for years and have a lot of knowledge built into them. If we combine FindPythonInterp and FindPythonLibs then the results should be similar to finding both packages individually. The combined module should check/validate COMPONENTS requested in the call to find_package. There could be Interp and Libs components such that the package can be found if one component is requested and the other is not available. When I've seen the need for a combined module discussed before, one issue that is commonly raised is that there should be separate FindPython2 and FindPython3 modules because the two languages are somewhat different and some projects may need to find both. Then there could also be a FindPython that accepts either version for projects that can support either. I'm not sure how variables should be named in each of the three modules, but their implementations should share as much code as possible. Further comments on the specific module implementation follow, though with the design requirements laid out above I doubt much of the code will be used as-is. I think this thread should first focus discussion on interface design and not work on the actual code yet. Thanks, -Brad - Currently the module depends on running the python executable. This can be allowed but cannot be required. The module must be able to work when cross-compiling where the libraries come with an executable that may not run on the host. Please read the cmake-developer(7) documentation on find modules: http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#find-modules In particular please use the proper naming convention for cached v. result variables. Also the module documentation needs to have proper .rst formatting. The PYTHON_EXEC variable should be called PYTHON_EXECUTABLE. (This may change depending on the v2/v3 discussion above.) For find_python_module, please provide documentation of the function using the .rst markup and ".. command::" directive. Also please look at using CMakeParseArguments rather than custom ARGC testing. - -- 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?
On 06/30/2015 03:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > it would be great if some people could step forward once > everything is running from my side to help get makefile and linux > support (and test other Visual Studio versions). Once you have it working in VS 2013 the other VS >= 2010 versions should be easy. I'm not sure about other generators yet. If you have good coverage in the test suite updates then that will make the task of adding support to other generators easier. For now you can have CMakeDetermineCSharpCompiler do a message(FATAL_ERROR) when CMAKE_GENERATOR is set to a value that is not supported. That can be lifted when the other generators implement the language. > About enable_language(): > > have the appropriate cmake-scripts in "Module" directory [snip] > Almost everything relevant goes in the target generator class > VisualStudio10TargetGenerator. Great! > Once done, do you want patchfiles here on the list or a pull > request from my fork on github? Please send patch files here as requested in CONTRIBUTING.rst. Please re-organize commits into a logical series of updates rather than the original unorganized development history. 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] C# support?
Yes, please do spell it out as CSharp. CS could mean about a billion things... On Tue, Jun 30, 2015 at 5:19 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > Sounds reasonable, > > > > my choice was motivated by the file extension of the C# source files (.cs) > and that it is shorter. But as Fortran seems to use the longer “Fortran” > description it might be a good idea to switch to “CSharp” as well … > > > > Michael > > > > From: Petr Kmoch [mailto:petr.km...@gmail.com] > Sent: Tuesday, June 30, 2015 10:18 AM > To: Stuermer, Michael SP/HZA-ZSEP > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] C# support? > > > > On Tue, Jun 30, 2015 at 9:21 AM, Stuermer, Michael SP/HZA-ZSEP > wrote: > > [...] > > About the language: > > Would it be ok to name the language in CMake "CS" instead of "CSharp"? I did > everything as "CS" so far... > > > > If I may provide an outsider's comment on this point, I would suggest > against this. For me, "CS" does not intuitively associate with C# - I > wouldn't know it means C# unless I read it somewhere stated explicitly. "C", > "CXX", "Fortran" are all obvious to me, "CS" is not. > > Then again, I have never used C#, so it might just be general unfamiliarity > on my part, in which case feel free to ignore this post. > > Petr > > > > > -- > > 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?
Sounds reasonable, my choice was motivated by the file extension of the C# source files (.cs) and that it is shorter. But as Fortran seems to use the longer “Fortran” description it might be a good idea to switch to “CSharp” as well … Michael From: Petr Kmoch [mailto:petr.km...@gmail.com] Sent: Tuesday, June 30, 2015 10:18 AM To: Stuermer, Michael SP/HZA-ZSEP Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? On Tue, Jun 30, 2015 at 9:21 AM, Stuermer, Michael SP/HZA-ZSEP mailto:michael.stuer...@schaeffler.com>> wrote: [...] About the language: Would it be ok to name the language in CMake "CS" instead of "CSharp"? I did everything as "CS" so far... If I may provide an outsider's comment on this point, I would suggest against this. For me, "CS" does not intuitively associate with C# - I wouldn't know it means C# unless I read it somewhere stated explicitly. "C", "CXX", "Fortran" are all obvious to me, "CS" is not. Then again, I have never used C#, so it might just be general unfamiliarity on my part, in which case feel free to ignore this post. Petr -- 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?
On Tue, Jun 30, 2015 at 9:21 AM, Stuermer, Michael SP/HZA-ZSEP < michael.stuer...@schaeffler.com> wrote: > [...] > > About the language: > > Would it be ok to name the language in CMake "CS" instead of "CSharp"? I > did everything as "CS" so far... > If I may provide an outsider's comment on this point, I would suggest against this. For me, "CS" does not intuitively associate with C# - I wouldn't know it means C# unless I read it somewhere stated explicitly. "C", "CXX", "Fortran" are all obvious to me, "CS" is not. Then again, I have never used C#, so it might just be general unfamiliarity on my part, in which case feel free to ignore this post. Petr -- 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?
Hi and thanks for all your answers, Let me give you some information how things are implemented so far and where my constraints in implementing C# support are: At the moment I have only Visual Studio 2013 available, which makes it hard for me to test any other generators. NMake is not a priority for me, but the concept of the Visual Studio generators in CMake is so nice implemented, that it should not be much of a problem to get this running. I will have a look on this once Visual Studio generators are working. I will be able to test some linux/mono functionality in VirtualBox, but I will most probably not have much time. We are working on Windows based software here and I will not be allowed to spent a vast amount of time working on non-project related topics. In short: it would be great if some people could step forward once everything is running from my side to help get makefile and linux support (and test other Visual Studio versions). About enable_language(): Working. From my knowledge it's mainly about have the appropriate cmake-scripts in "Module" directory. That's done, my test project builds well with it. Ok, the CMakeTest... script simply sets "WORKS" to true ... that could be improved ... About .csproj files: It's almost done, the files are generated already and working well. There still needs to be some cleaning and generalization to use parameters instead of hard coded information. About intrusiveness: Almost everything relevant goes in the target generator class VisualStudio10TargetGenerator. The necessary .cmake files for the language are added and some minor changes to other generator sources are needed (for setting target type GUID in .sln etc.). All changes so far are made to be as minimal as possible to the original cmake sources and I believe it blends in quite well. Credit goes to the guys who implemented the VisualStudio generator concept with the flagmaps. You need some time to understand it, but once you've got it it's really great. About C#/.NET: I'm new to .NET and C# as well, but it seems not to provide too many surprises. Nevertheless some challenges remain to come up with a good solution for C# integration. It's mainly about reference handling. I have a working example at the moment, but it could be improved further. About the language: Would it be ok to name the language in CMake "CS" instead of "CSharp"? I did everything as "CS" so far... About contributing: Once done, do you want patchfiles here on the list or a pull request from my fork on github? --- If someone is interested in the development so far, you can check out my CMake fork here (have a look at the "csharp" branch): https://github.com/micst/CMake.git The test project with mixed C++/C# targets, cross-referencing from C++ <--> managed C++ <--> C# can be found here: https://github.com/micst/CMakeCSharpTest.git best regards, Michael > -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On > Behalf Of David Cole via cmake-developers > Sent: Monday, June 29, 2015 7:31 PM > To: Brad King > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] C# support? > > The C# compiler, csc.exe, takes all its arguments at once in one call > to build a library or executable. Listing all the sources, and its > references (other libraries it depends on) all at once. You can do it > as command line arguments, or as contents of a response file, or a > combination or arguments plus response file. > > Conceptually, it's "just like Java." > > They do have separate project files for it with VS, though. The > generators will need code to generate *.csproj files, rather than > custom commands in a vcxproj file, to make it seem like it's really > well-integrated with VS. Not sure if *.csproj files have evolved much > over the last few releases of VS -- I'd expect the major challenge with > this to be making sure CMake generates proper *.csproj files for > however many versions of VS it would take to make it acceptable. > > > D > > > > On Mon, Jun 29, 2015 at 1:05 PM, Brad King > wrote: > > On 06/26/2015 10:47 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > >> Does it have a realistic chance to be accepted for upstream > > > > Yes, so long as it comes with proper tests and is not too intrusive > on > > the overall design/implementation of CMake. > > > > In order to enable use of C# sources we should get > > > > enable_language(CSharp) > > > > to work. This is likely straightforward with the VS generators. > > > > One question is how things should be done for the Makefile and Ninja > > generators. For these we need to construct command line invocations > > of the compiler. I'm not very familiar with C#. > > Does it need separate compilation with dependencies or should one > > simply invoke the compiler with the entire list of sources in a > > response file or something? > > > > Thanks
