[CMake] [ANNOUNCE] CMake 3.11.0-rc4 is now ready for testing

[Robert Maynard]

I am proud to announce the fourth CMake 3.11 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.11

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.11/release/3.11.html

Some of the more significant changes in CMake 3.11 are:

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CMake 3.11 Release Notes


Changes made since CMake 3.10 include the following.


New Features



Platforms
-

* TI C/C++ compilers are now supported by the "Ninja" generator.


Generators
--

* The "CodeBlocks" extra generator learned to check a
  "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
  identification value to place in the project file.

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.


Commands


* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC"
  and "NETRC_FILE" options to specify use of a ".netrc" file.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.


Variables
-

* A "CMAKE_GENERATOR_

Re: [CMake] Can't find Boost with Visual Studio 2017

[David Demelier]

On Sat, 2018-03-17 at 23:15 +0100, Volker Enderlein wrote:
> Hi David,
> 
> Boost changed its naming scheme starting from version 1.66. So its
> not 
> your fault but the FindBoost.cmake does not know how to handle the
> new 
> scheme. Try to use one of the 3.11.0-rc[1-3] versions that has the 
> proper naming scheme handling of 1.66 or use the 1.65.1 that is the
> last 
> version with the old naming scheme.
> 

Hello,

Indeed, it works with CMake 3.11, thanks a lot :)

-- 
David
-- 

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] Make ctest spit out xml file (without dashboard)

[Eric Noulard]

2018-03-19 13:14 GMT+01:00 Craig Scott :

>
>
> On Mon, Mar 19, 2018 at 10:39 PM, Eric Noulard 
> wrote:
>
>> Hi there,
>>
>> Is it possible to make ctest spit out its result in an xml formatted file
>> without
>> sending it to some dashboard. ?
>>
>
> Yes, you can control the individual steps of a full dashboard run and just
> leave out the submit step. For example:
>
> ctest -T Start -T Update -T Configure -T Build -T Test -T Coverage -T
> MemCheck
>
> Leave out any of the above -T actions you don't need. XML result files
> will be in a Testing/MMDD-hhmm directory and log files in
> Testing/Temporary. The Start action creates a new MMDD-hhmm timestamp
> directory that the rest of the steps will then store their XML result files
> in. The first line of the file at Testing/TAG records that timestamp and
> the second line in there you won't care about if not submitting the results
> to a dashboard.
>
> Hopefully that gets you far enough along to what you need.
>

This is indeed far just enough for my needs.
Thank you very much Craig.


-- 
Eric
-- 

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] Generator Expressions and FetchContent

[Saad Khattak]

I do use target_link_libraries when it comes to C++ projects and it works
wonderfully for them. However, in this case, my base project has a bunch of
helper files with CMake functionality that help me work with and build my
library of projects (which you can see here
https://github.com/2LoC/tl_base_ci).

Of course, these helper .cmake files (with the functionality I want) are in
the tl_base_ci project which can be either (1) cloned separately, built,
(2) Installed without building, or (3) cloned through ExternalProject_Add
(which I am trying to convert to FetchContent). In all cases, the include
directories might differ, which is why I use rely on the generator
expressions expanding.

In projects depending on tl_base_ci (e.g.
https://github.com/2LoC/tl_proj_template), I have CMake includes like this:

include("${tl_base_ci_INCLUDE_DIRECTORY}/tl_base_ci/tl_common.cmake") # in
the actual project, it's slightly different as it searches for the file in
a list of directories returned by
get_target_property(... INTERFACE_INCLUDE_DIRECTORIES)

Where the tl_base_ci_INCLUDE_DIRECTORY might differ. So ultimately I was
hoping for a way to reliably include the helper .cmake files (i.e. figure
out tl_base_ci's include directory path). I did that with
get_target_property(...) which worked great for ExternalProject_Add, but
did not work so well for FetchContent because the generator expressions did
not expand.

Hopefully I was able to explain the problem well. If there is any
confusion, please let me know.



On Mon, Mar 19, 2018 at 7:11 AM Craig Scott  wrote:

> On Mon, Mar 19, 2018 at 8:25 AM, Saad Khattak 
> wrote:
>
>> Thank you for the clarification Craig.
>>
>> >> If you made your main target link against LibA, you'd see that CMake
>> automatically expands out the generator expressions when it constructs the
>> link command line for main, so the example as it stands doesn't actually
>> have any error.
>>
>> In my actual project, a library like LibA has .cmake files that can be
>> included by dependent projects to reuse. Of course, CMake `include` does
>> not get affected by target_link_libraries.
>>
>> I would like dependent projects to have the ability to use an existing
>> clone of LibA, if found (e.g. using find_package), otherwise clone locally
>> for using ExternalProject_Add which I am now trying to refactor to
>> FetchContent. Another option open to dependent projects is to force the
>> FetchContent on all repositories regardless of what find_package returns
>> (this is great for testing locally to ensure I have no uncommitted,
>> unpushed changes).
>>
>> Using existing clones is a way to ensure that every project dependent on
>> LibA doesn't clone it's own copy (unless forced to do so).
>>
>> To allow the possibility for any dependent project to include the .cmake
>> files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property
>> (using get_target_property) for LibA and then include the .cmake utility
>> files like this:
>>
>> include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake)
>>
>> Perhaps I am approaching the problem incorrectly? Essentially, I would
>> like a way to reliably include .cmake files found in LibA's include folder
>> regardless of how LibA was acquired (e.g. cloned and built and/or installed
>> separately or acquired using FetchContent). In my case, I could only think
>> of the above as a reliable way to include the files.
>>
>
> Rather than focusing on including files, I would choose to base things
> around targets. If the rest of your project simply links against the
> required target name, the target itself should bring with it any transitive
> dependencies such as required header search paths, dependent libraries that
> must also be linked, etc. These are the INTERFACE_... properties that can
> be set on a target, usually by commands such as
> target_include_directories(foo INTERFACE ...), target_link_libraries(foo
> INTERFACE ...), etc. When building directly from your source tree, the
> targets will be directly available. When using find_package(), the package
> should provide import targets. The rest of your project shouldn't really
> need to care which one of the two it is dealing with. This is the
> recommended way to structure a situation like this. You shouldn't need to
> also pull in a secondary .cmake file in most circumstances, but maybe I'm
> missing something about your particular situation.
>
>
>
>>
>> On Sun, Mar 18, 2018 at 4:22 PM Craig Scott 
>> wrote:
>>
>>> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak 
>>> wrote:
>>>
 Absolutely. Please find the example project here:
 https://github.com/samaursa/cmake_fetch_content_and_generator_expressions


 The repository README also includes the output from running
 `./setup.sh`.

>>>
>>>
>>> Okay that's much clearer, thanks. The example is doing what I'd expect
>>> and the generator expressions are also expected to be visible at the point
>>> your example is printing them. If you made your m

Re: [CMake] Make ctest spit out xml file (without dashboard)

[Craig Scott]

On Mon, Mar 19, 2018 at 10:39 PM, Eric Noulard 
wrote:

> Hi there,
>
> Is it possible to make ctest spit out its result in an xml formatted file
> without
> sending it to some dashboard. ?
>

Yes, you can control the individual steps of a full dashboard run and just
leave out the submit step. For example:

ctest -T Start -T Update -T Configure -T Build -T Test -T Coverage -T
MemCheck

Leave out any of the above -T actions you don't need. XML result files will
be in a Testing/MMDD-hhmm directory and log files in Testing/Temporary.
The Start action creates a new MMDD-hhmm timestamp directory that the
rest of the steps will then store their XML result files in. The first line
of the file at Testing/TAG records that timestamp and the second line in
there you won't care about if not submitting the results to a dashboard.

Hopefully that gets you far enough along to what you need.



>
> I only need something xml-parsable ctest output locally.
>
> --
> Eric
>
> --
>
> 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
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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 Frameworks and Bitcode

[Brad King]

On 03/12/2018 10:36 AM, Cameron Palmer wrote:
> So after a bit of hacking it seems that Cmake should provide something like:
> 
> CMAKE_OSX_BITCODE_ENABLE

For reference, this refers to a previous post:

Bitcode and CMake
https://cmake.org/pipermail/cmake/2018-March/067191.html

with the goal of using `-fembed-bitcode` while avoiding a warning:

ld: warning: -headerpad_max_install_names is ignored when used with 
-bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)

> Which would pass -fembed-bitcode to the compiler and linker and remove
> the option in Darwin.cmake for -Wl,-headerpad_max_install_names in
> CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS.

One may avoid the `-headerpad_max_install_names` option with this:


https://cmake.org/cmake/help/v3.11/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html

There is no reason to build with any rpath set for the build tree
when one cannot run the binaries on the macOS host anyway.

-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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Make ctest spit out xml file (without dashboard)

[Eric Noulard]

Hi there,

Is it possible to make ctest spit out its result in an xml formatted file
without
sending it to some dashboard. ?

I only need something xml-parsable ctest output locally.

-- 
Eric
-- 

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] Generator for Visual Studio Code (Ubuntu)

[Stephen McDowell]

You may also find this article useful, it seems to explain how to configure the 
JSON files you need to for more complicated build systems: 
https://medium.com/audelabs/c-development-using-visual-studio-code-cmake-and-lldb-d0f13d38c563
 


They were writing for Linux / OS X, and you’ll see that they’re just using 
cmake -G 'Unix Makefiles’ in their tasks.json.


-- 

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] Generator Expressions and FetchContent

[Craig Scott]

On Mon, Mar 19, 2018 at 8:25 AM, Saad Khattak  wrote:

> Thank you for the clarification Craig.
>
> >> If you made your main target link against LibA, you'd see that CMake
> automatically expands out the generator expressions when it constructs the
> link command line for main, so the example as it stands doesn't actually
> have any error.
>
> In my actual project, a library like LibA has .cmake files that can be
> included by dependent projects to reuse. Of course, CMake `include` does
> not get affected by target_link_libraries.
>
> I would like dependent projects to have the ability to use an existing
> clone of LibA, if found (e.g. using find_package), otherwise clone locally
> for using ExternalProject_Add which I am now trying to refactor to
> FetchContent. Another option open to dependent projects is to force the
> FetchContent on all repositories regardless of what find_package returns
> (this is great for testing locally to ensure I have no uncommitted,
> unpushed changes).
>
> Using existing clones is a way to ensure that every project dependent on
> LibA doesn't clone it's own copy (unless forced to do so).
>
> To allow the possibility for any dependent project to include the .cmake
> files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property
> (using get_target_property) for LibA and then include the .cmake utility
> files like this:
>
> include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake)
>
> Perhaps I am approaching the problem incorrectly? Essentially, I would
> like a way to reliably include .cmake files found in LibA's include folder
> regardless of how LibA was acquired (e.g. cloned and built and/or installed
> separately or acquired using FetchContent). In my case, I could only think
> of the above as a reliable way to include the files.
>

Rather than focusing on including files, I would choose to base things
around targets. If the rest of your project simply links against the
required target name, the target itself should bring with it any transitive
dependencies such as required header search paths, dependent libraries that
must also be linked, etc. These are the INTERFACE_... properties that can
be set on a target, usually by commands such as
target_include_directories(foo INTERFACE ...), target_link_libraries(foo
INTERFACE ...), etc. When building directly from your source tree, the
targets will be directly available. When using find_package(), the package
should provide import targets. The rest of your project shouldn't really
need to care which one of the two it is dealing with. This is the
recommended way to structure a situation like this. You shouldn't need to
also pull in a secondary .cmake file in most circumstances, but maybe I'm
missing something about your particular situation.



>
> On Sun, Mar 18, 2018 at 4:22 PM Craig Scott 
> wrote:
>
>> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak 
>> wrote:
>>
>>> Absolutely. Please find the example project here: https://github.com/
>>> samaursa/cmake_fetch_content_and_generator_expressions
>>>
>>> The repository README also includes the output from running
>>> `./setup.sh`.
>>>
>>
>>
>> Okay that's much clearer, thanks. The example is doing what I'd expect
>> and the generator expressions are also expected to be visible at the point
>> your example is printing them. If you made your main target link against
>> LibA, you'd see that CMake automatically expands out the generator
>> expressions when it constructs the link command line for main, so the
>> example as it stands doesn't actually have any error.
>>
>> Generator expressions are not expanded when CMake is processing the files
>> (called the *configure* stage), they are expanded only when writing out
>> the Makefiles during the *generation* stage. When running cmake from the
>> command line, one doesn't tend to think of these two phases as being
>> distinct, but you can see it at the end of the cmake log with these two
>> messages:
>>
>> -- Configuring done
>> -- Generating done
>>
>> It is clearer when using the CMake GUI application because you get two
>> different buttons, one for Configure and another for Generate, so you have
>> to trigger both phases manually. So if you look at the contents of various
>> properties and variables with CMake commands like message(...), you are
>> doing that during the configure stage and therefore will see unexpanded
>> generator expressions.
>>
>>
>>
>>
>>>
>>> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott 
>>> wrote:
>>>
 Can you provide a small project example that can be used to demonstrate
 your problem? The specifics of how you are doing things may be important.


 On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak 
 wrote:

> Hi,
>
> ExternalProject_Add builds, generates and installs and thus any
> generator expressions used will be expanded by the time another library
> uses it.
>
> For example, if I add a library LibA using ExternalProject_Add, I can
> then query th

Re: [CMake] Generator for Visual Studio Code (Ubuntu)

[Mateusz Loskot]

(you missed to reply to the mailing list!)

On 19 March 2018 at 11:58, Richard Frank  wrote:
> Ok fair enough. So. I can output Unix make files and VS code can load those?

Yes.

If you have read the vscode-cmake extension docs
https://vector-of-bool.github.io/,
you would have seen that there is no generator required, you can choose.

Consider another example:
if you use Visual Studio 2017 with its CMake integration [1],
you don't have to limit yourself to VisualStudio/MSBuild generator just becasue
you use CMake inside Visual Studio. You can use Ninja too.

[1] 
https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
-- 

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] Generator for Visual Studio Code (Ubuntu)

[Mateusz Loskot]

On 19 March 2018 at 11:51, Richard Frank  wrote:
> Yes I have that plugin. But for more complex build systems that build
> multiple products, running CMake from a shell script, I wondered what
> generator would be used,

FWIW, there no such thing as CMake generator for "Visual Studio Code".
VSCode is generator-agnostic.
For current list of generators, refer to the CMake docs.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
-- 

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] Generator for Visual Studio Code (Ubuntu)

[Richard Frank]

Yes I have that plugin. But for more complex build systems that build multiple 
products, running CMake from a shell script, I wondered what generator would be 
used,

Sent from my iPad

> On Mar 18, 2018, at 10:07 PM, Andrew Gaspar  wrote:
> 
> Hm, I’m not sure what you mean by built in support, but there is an excellent 
> plugin you should install: 
> https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools
>  
> It gives you easy interface extensions for building, debugging, or testing 
> your project. You shouldn’t need to use a specific Generator – by default 
> CMake Tools will use the default generator (I think). So Makefiles should be 
> fine.
>  
> Is that what you were looking for?
>  
> Andrew Gaspar
>  
> From: CMake  on behalf of Richard Frank 
> 
> Sent: Sunday, March 18, 2018 4:18:34 PM
> To: cmake@cmake.org
> Subject: [CMake] Generator for Visual Studio Code (Ubuntu)
>  
> Hi
> 
> I’m trying out Visual Studio Code on Ubuntu 16.04. There’s support for CMake 
> built in but if I use CMake externally was generator should I use?
> 
> Thanks 
> 
> Rick Frank
> -- 
> 
> Powered by 
> https://eur03.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435%7C1%7C0%7C636570119238976995&sdata=WxauxUOq51ZRIp656qtFNI5U16CBz3kFhCIYUwUoP94%3D&reserved=0
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435%7C1%7C0%7C636570119238976995&sdata=lwzT5B3kjsfTjMmeEIlrCtGFfekNSOVPcxmjvhKs64s%3D&reserved=0
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: 
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435%7C1%7C0%7C636570119238976995&sdata=eSXn18Hr1jYlsgSr7tZd6dvoLKb6x9o2ZdwD%2FGe2o%2B8%3D&reserved=0
> CMake Consulting: 
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435%7C1%7C0%7C636570119238976995&sdata=4q%2By3fqm11Du4ZfavRlSXjuX2VkBeYpfjx57cq2Xq6A%3D&reserved=0
> CMake Training Courses: 
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435%7C1%7C0%7C636570119238976995&sdata=FRKO1XfW8Ig63ewieK7fyLjSd%2B82m8a2GQc9li5KSU4%3D&reserved=0
> 
> Visit other Kitware open-source projects at 
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435%7C1%7C0%7C636570119238976995&sdata=c7EIM23%2FTAWSfOizVV7nJq2xo9fr1Yt12%2FZE3jxs780%3D&reserved=0
> 
> Follow this link to subscribe/unsubscribe:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&data=02%7C01%7C%7C593cf50557c1431db0b708d58d269787%7C84df9e7fe9f640afb435%7C1%7C0%7C636570119238976995&sdata=UhiwQSBUPtslzKxdRzig0iRkU6uaTGd8Uq55o2Nbn%2BY%3D&reserved=0
-- 

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