Re: [CMake] printing CMAKE_CXX_FLAGS_* based on build type
Are you using a generator that uses CMAKE_BUILD_TYPE and has it set to a known
value? Build type doesn’t have to be set and multi-config generators don’t use
it.
On Fri, Sep 27, 2019, at 4:18 PM, Zdenko Podobny wrote:
> Hello,
>
> I try to print CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one line
> statement but is does not work for me:
>
> message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options:
> ${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")
>
> Produce empy result, but
> message( STATUS "CXX compiler Release build options:
> ${CMAKE_CXX_FLAGS_RELEASE}")
> works as expected.
> Is it possible to do it in one line or I have to use if/elseif ?
>
> Zdenko
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
--
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:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86
As I recall for myself, simply using the Visual Studio Generator with the -A option was all that was needed to build for Win32. You don't need a toolchain file because the generator already knows how to setup a Visual Studio Project to target Win32. Even the documentation for cross-compiling doesn't show a need to setup toolchain file for cross compiling in this case. I personally never seen anyone try to use the Ninja generator via command line CMake and use the cl.exe compiler. I've only seen that using Visual Studio to open a CMakeLists.txt file it can produce a Ninja project. But even MS documentation states that it doesn't always work. https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64 This says you should be able to open the proper development window and use Ninja. The output shows that in the environment you are using it doesn't even know how to use cl.exe to even determine with compiler it is. Maybe not all the proper environment variables and paths are being set correctly when using the compiler. -- F On Tue, Sep 17, 2019, at 3:11 PM, Joao Pedro Abreu De Souza wrote: > Thanks, I'll check it out. > > The toolchain file, as is, can generate ninja builds that can be used to > generate a executable, but when I execute them, he say : > > ``` > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 12.0/VC/bin/amd64_x86/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken > CMake Error at C:/Program > Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message): > The C compiler > > "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64_x86/cl.exe" > > is not able to compile a simple test program. > > It fails with the following output: > > Change Dir: > C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp > > Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_0dfb4 && > [1/2] Building C object CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj > FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj > "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe" -o > CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj -c testCCompiler.c > ninja: build stopped: subcommand failed. > > > > > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:2 (project) > ``` > > Em ter, 17 de set de 2019 às 16:02, Juan Sanchez > escreveu: >> From my brief research, it looks like the Microsoft version of CMake may >> have Ninja support. >> >> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/ >> >> >> Regards, >> >> Juan >> >> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza >> wrote: >>> So, only the Visual Studio generator use the Arch option? I try generate >>> ninja build, but cmake(3.15.3) and the answer was >>> >>> ``` >>> $ cmake -B build -S . -G "Ninja" -A Win32 >>> CMake Error at CMakeLists.txt:2 (project): >>> Generator >>> >>> Ninja >>> >>> does not support platform specification, but platform >>> >>> Win32 >>> >>> was specified. >>> >>> >>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage >>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage >>> -- Configuring incomplete, errors occurred! >>> See also >>> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log". >>> ``` >>> >>> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez >>> escreveu: Hello, My impression that targeting 32 bit depends on what generator you are using. https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html It looks like cmake now has: * `cmake -G "Visual Studio 15 2017" -A Win32` * `cmake -G "Visual Studio 15 2017" -A x64` It used to be that the default target platform was Win32, and you had to specify Win64 in the generator string to target a 64 bit build. For example with Visual Studio 2015 https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html For compatibility with CMake versions prior to 3.1, one may specify a target platform name optionally at the end of the generator name. This is supported only for: `Visual Studio 14 2015 Win64` Specify target platform `x64`. `Visual Studio 14 2015 ARM` Specify target platform `ARM`. Regards, Juan On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza wrote: > cl from visual studio 2017. > > Em ter, 17 de set de 2019 03:26, Stéphane Ancelot > escreveu: >> Hi, >> That first depends on which compiler you will use ? >> Regards,
Re: [CMake] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)
https://github.com/microsoft/vscode-cmake-tools/issues/752 states that it ran
out of stack and the log shows what looks like to be involved with a recursive
loop in some CMakeLists.txt. A call depth of 27491 seems a bit excessive.
After the second call to FindPackage it just seems to be doing the same thing
over and over again.
I'd think a newer version of CMake would complain about too much recursion in
the project files.
Does the project work on the command line without involving VSCode?
It could be something different in the environment if it works on the command
line but not as server instance in VSCode.
--
F
On Wed, Sep 4, 2019, at 12:22 PM, Christopher Dawes wrote:
> Hi there, we are experiencing a crash when working with VSCode on Ubuntu:
>
> Brief Issue Summary
> When starting up VSCode using the CMake extension i get this error on all my
> projects, the application terminates pretty quickly. What’s happening is
> cmake server is spawned and then crashes; i’m afraid i’m uncertain what
> commands are exchanged. I logged the issue against the cmake extension here
> https://github.com/microsoft/vscode-cmake-tools/issues/752 however it looks
> like the issue is with cmake rather than the way it’s being used.
> Platform and Versions
> * Operating System: Ubuntu 18.04
> * CMake Version: 3.10.2
> * VSCode Version: 1.37.1
> * CMake Tools Extension Version: 1.13
> * Compiler/Toolchain: GCC 7.4.0-1ubuntu1~18.04.1 with Ninja
> Other Notes/Information
> I've run with debug symbols however it's too big (33MB) to attach here, see
> https://www.dropbox.com/s/cl7z4cxd5oyuvbr/with_symbols.txt?dl=0
> Here's a small excerpt:
> Thread 1 (Thread 0x7fce40c3a780 (LWP 28685)):
#0 std::__cxx11::basic_string, std::allocator >::_M_length (this=, __length=)
at /usr/include/c++/7/bits/basic_string.h:172
No locals.
#1 std::__cxx11::basic_string, std::allocator >::_M_set_length (__n=, this=)
at /usr/include/c++/7/bits/basic_string.h:205
No locals.
#2 std::__cxx11::basic_string, std::allocator >::basic_string
(this=0x7ffdee7d5e40) at /usr/include/c++/7/bits/basic_string.h:423
No locals.
#3 cmsys::SystemTools::FileIsDirectory (inName=...) at
./Source/kwsys/SystemTools.cxx:2865
length =
name =
local_buffer =
string_buffer =
last =
fs =
#4 0x55d2c7efa231 in cmListFile::ParseFile
(this=this@entry=0x7ffdee7d7010, filename=0x55d2ca803700
"/usr/local/bp/share/cmake/FindLibXml2.cmake", messenger=0x55d2c8da6110,
lfbt=...) at ./Source/cmListFileCache.cxx:139
parseError =
#5 0x55d2c7ca8c63 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0,
filename=, noPolicyScope=noPolicyScope@entry=false) at
./Source/cmMakefile.cxx:444
filenametoread = {static npos = 18446744073709551615, _M_dataplus = {>
= {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803700
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43,
{_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000",
_M_allocated_capacity = 45}}
incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false,
CheckCMP0011 = false, ReportError = true}
listFile = {Functions = { >> = {_M_impl = {> =
{<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x0, _M_finish = 0x0,
_M_end_of_storage = 0x0}}, }}
#6 0x55d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8034c0,
args=...) at ./Source/cmIncludeCommand.cxx:123
readit =
optional =
noPolicyScope =
fname = {static npos = 18446744073709551615, _M_dataplus = {> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803640
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43,
{_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000",
_M_allocated_capacity = 43}}
resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7120 ""},
_M_string_length = 0, {_M_local_buf =
"\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity =
390842023936}}
fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803560
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43,
{_M_local_buf = "-\000\000\000\000\000\000\000`5\200\312\322U\000",
_M_allocated_capacity = 45}}
gg = 0x55d2c8df16a0
listFile = {static npos = 18446744073709551615, _M_dataplus = {> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803680
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43,
{_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#7 0x55d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8034c0,
args=..., status=...) at ./Source/cmCommand.cxx:19
expandedArguments = {, std::allocator >, std::allocator, std::allocator
> > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator,
Re: [CMake] modify cmake build arguments
On Thu, 2019-08-29 at 18:27 +0100, hex wrote: > hello community, > > CMake builds a C project with gcc -o target_name. I have a compiler > very similar to GCC and I am trying configure CMake C language for > it. > > The compiler does not support the -o argument when linking objects. I > wonder if there is a way to remove or modify this argument, maybe > through one of the properties on targets? > > thank you Your best bet would be to modify the CMake source code to support your compiler. (Upstreaming your changes would be welcome.) As a matter of interest, what does it use instead of -o? Kyle >>> For linking objects it would be overriding CMAKE_C_LINK_EXECUTABLE: For example from the TI-C.cmake file: set(CMAKE_C_LINK_EXECUTABLE " --run_linker --output_file= --map_file=.map ")-- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] modify cmake build arguments
On Fri, Aug 30, 2019, at 1:47 AM, Eric Doenges wrote: > On 29.08.2019 22:38, fdk17 wrote: >> On Thu, Aug 29, 2019, at 2:52 PM, Kyle Edwards via CMake wrote: >>> On Thu, 2019-08-29 at 18:27 +0100, hex wrote: >>> > hello community, >>> > >>> > CMake builds a C project with gcc -o target_name. I have a compiler >>> > very similar to GCC and I am trying configure CMake C language for >>> > it. >>> > >>> > The compiler does not support the -o argument when linking objects. I >>> > wonder if there is a way to remove or modify this argument, maybe >>> > through one of the properties on targets? >>> > >>> > thank you >>> >>> Your best bet would be to modify the CMake source code to support your >>> compiler. (Upstreaming your changes would be welcome.) >>> >>> As a matter of interest, what does it use instead of -o? >>> >>> Kyle >> >> If you are using the Makefile generator then try: >> https://cmake.org/cmake/help/latest/variable/CMAKE_USER_MAKE_RULES_OVERRIDE.html >> You may then be able to provide the rules needed, refer to >> "Modules/CMakeCInformation.cmake". >> The way I understand it is that the rule templates are used by the Makefile >> generator. >> > The way I understand the documentation, CMAKE_USER_MAKE_RULES_OVERRIDE > applies for all generators, not just the Makefile one. What you are > apparently supposed to do is create a file that sets all the "rule variables" > as required (in this case, CMAKE_C_COMPILE_OBJECT), and then include that > file via CMAKE_USER_MAKE_RULES_OVERRIDE. I'm not sure if these 'rule > variables' are documented anywhere - but you can look into " is installed>/share/cmake-/Modules/Compiler" for inspiration. > Another good starting point would be > "<...>/share/cmake-/Modules/CMakeCInformation.cmake". > > With kind regards, > Eric > > *Dr. Eric Dönges * > Senior Software Engineer > I could have been clearer about the use of CMAKE_USER_MAKE_RULES_OVERRIDE. It wasn't my intention to suggest that only the Makefile generator makes use of this variable. In a quick check I only saw the CMAKE_C_COMPILE_OBJECT rule being used by the Makefile (and maybe the Ninja) generator and I know that it isn't used by the GHS Multi generator. Which is why I mentioned the Makefile generator specifically in regards to changing a "-o" to something else. If you look at Modules/CMakeCInformation.cmake it will only define a rule if it hasn't already been previously set either by the definitions in the compiler / platform files that get included first and then by the override file. You won't need to define all the rules in the override file just the ones you care to change. Also not all of the rules that get defined applies to all of generators (such as CMAKE_C_COMPILE_OBJECT as already mentioned). A good example to follow is Modules/Compiler/TI-C.cmake to change a "-o" to something else. From TI-C.cmake: set(CMAKE_C_COMPILE_OBJECT " --compile_only --c_file= --output_file=") Then as suggested the override file could be the basis of a new compiler file that gets submitted upstream. -- F-- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] modify cmake build arguments
On Thu, Aug 29, 2019, at 2:52 PM, Kyle Edwards via CMake wrote: > On Thu, 2019-08-29 at 18:27 +0100, hex wrote: > > hello community, > > > > CMake builds a C project with gcc -o target_name. I have a compiler > > very similar to GCC and I am trying configure CMake C language for > > it. > > > > The compiler does not support the -o argument when linking objects. I > > wonder if there is a way to remove or modify this argument, maybe > > through one of the properties on targets? > > > > thank you > > Your best bet would be to modify the CMake source code to support your > compiler. (Upstreaming your changes would be welcome.) > > As a matter of interest, what does it use instead of -o? > > Kyle If you are using the Makefile generator then try: https://cmake.org/cmake/help/latest/variable/CMAKE_USER_MAKE_RULES_OVERRIDE.html You may then be able to provide the rules needed, refer to "Modules/CMakeCInformation.cmake". The way I understand it is that the rule templates are used by the Makefile generator. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for GHS
On Thu, Aug 29, 2019, at 1:51 AM, Deepan Muthusamy (RBEI/ESP-IS44) via CMake wrote: > I want to compile c and c++ code in GHS compiler for renesas controller. > > For Mingw compiler, My code is compiling successfully. But I want to compile > for GHS. > > I have compiler available at this path "C:/ghs/comp_201255_RH850". > > When generate, I gave option as “specify native compiler”. > C compiler : C:/ghs/comp_201255_RH850/ccrh850.exe > C++ compiler: C:/ghs/comp_201255_RH850/cxrh850.exe > > > I am getting the following error. > > > > Green Hills MULTI: -A not specified; defaulting to "arm" > Green Hills MULTI: GHS_TARGET_PLATFORM not specified; defaulting to > "integrity" > Green Hills MULTI: -T not specified; defaulting to > "C:/ghs/comp_201255_RH850" > The C compiler identification is GHS > The CXX compiler identification is GHS > Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe > Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe -- broken > CMake Error at > D:/e-bike/cmake-3.14.3-win64-x64/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:60 > (message): > The C compiler > > "C:/ghs/comp_201255_RH850/ccrh850.exe" > > is not able to compile a simple test program. > > It fails with the following output: > > Change Dir: D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeTmp > > Run Build Command(s):C:/ghs/comp_201255_RH850/gbuild.exe -top > CMAKE_TRY_COMPILE.top.gpj cmTC_d9171.gpj > Error: Could not read target file: arm_integrity.tgt > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:6 (project) > Configuring incomplete, errors occurred! > See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeOutput.log". > See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeError.log". > > > > So How to configure GHS for CMAKE build. Please advice me in this, Thanks in > advace > > > > > > Best regards, > > *Muthusamy Deepan > RBEI/ESP6 * https://cmake.org/cmake/help/v3.15/generator/Green%20Hills%20MULTI.html It sound's like you want to generate a GHS Multi project. The "CMAKE__COMPILER" variables are not used for compiling GHS Multi projects. The GHS build tool gbuild handles those kinds of details. You do need to set GHS_TARGET_PLATFORM and specify the target architecture so that a correct GHS Multi project for your target can be built. You can inspect the GHS example projects delivered to you as part of your GHS installation to determine those values. Usually its something like "arm" and "integrity", which is one of the reasons those were chosen as the default. I'd highly recommend reading the GHS manual and looking at the example projects to understand how a GHS Multi project works if you are not already familiar with it. -- F -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] FetchContent/ExternalProject and URL_HASH
On Mon, Jul 22, 2019, at 11:51 AM, Dustyn Blasig wrote: > *"I don't think it is realistic to expect CMake or the underlying tools to > still give you a successful file download if you interrupt it. ;)"* > > Sorry, I didn't word that well : ) > > I was curious if CMake uses handlers behind the scenes similar to GNU Make > such that if a signal occurs it will cleanup any partially-written files so > the next time you build it will retry those targets. In this case, if the > download is interrupted, will CMake know it needs to redo the download? Are > the checksum files used to verify the download was successful, or really only > useful for authenticity like the man-in-the-middle attacks? > > I definitely like the download and configure once and reuse the download > offline part, that is useful! > I recall FetchContent being smart enough to determine that it was interrupted by user. The time stamps typically don't get updated until after successfully completing the fetch and configure. So it’ll just redo the pieces that needs to be updated or didn’t run in the first place. The checksums are used to verify the download was successful. Typical Ethernet and TCP/IP is not robust enough to detect single bit errors in large downloads. It’s one of the reasons why md5sum accompanies ISO downloads. Less of an issue with small items but still can happen. One reason for not downloading checksum file is that you don’t know if package had an issue or if the checksum file had an issue. You wouldn’t want to download a large file because the checksum file had an error. I can see how having this feature would be beneficial to you but you may just be forced to download checksum independently and parse it first. Then use contents for the real item to be downloaded. — F-- 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: https://cmake.org/mailman/listinfo/cmake
