[cmake-developers] CMake 3.9.3 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.9.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.9.3 since 3.9.2:

Brad King (3):
  VS: Do not consider MAP_IMPORTED_CONFIG_ on non-imported targets
  bootstrap: Fix running multiple times in-source
  CMake 3.9.3

Maarten de Vries (1):
  vim: Remove default setting of expandtab

Roger Leigh (1):
  FindBoost: Add support for Boost 1.65.0 and 1.65.1 to CMake 3.9

Rolf Eike Beer (1):
  CTest: fix crash if source file for coverage cannot be found

Sebastian Holtermann (2):
  Autogen: Backport autogen target dependency as file dependency fix
  Autogen: Tests: Backport tests for _autogen target dependencies
-- 

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] Custom script invocation from imported target

[Robert Maynard]

Hi,

You are correct that as it stands it is challenging to add custom
linking / compilation steps in CMake for moc

The challenge with these approaches is that you

1. The unfortunate truth is that a cmake configure time script lacks
the required information. Numerous things such as the location of
libraries or config type need to be delayed to generation or execution
time.

2. Things such as CUDA separable compilation, and I believe MOC, and
HSL/GSL also need to invoke the original COMPILATION and LINK  steps
but now with additional libraries or objects that need to be added.

3. My thinking is you really wanting better ability to add custom
languages to CMake. Have you explored having SYCL as a custom
language?

4. With CMake 3.9 CUDA ptx compilation is natively supported using
OBJECT libraries and the CUDA_PTX_COMPILATION property

On Wed, Sep 20, 2017 at 8:12 AM, Nagy-Egri Máté Ferenc via
cmake-developers  wrote:
> Hi!
>
>
>
> I am trying to improve the developer experience of SYCL users for both those
> using triSYCL and ComputeCpp alike. (TL;DR: SYCL is CUDA of OpenCL, triSYCL
> being a non-conforming playground implementation built atop OpenMP, while
> ComputeCpp is the first (and only) conforming GPU-accelerated
> implementation.) Although they are two wildly different implementations, it
> would come in handy to mix the two, having Debug builds rely on triSYCL (for
> the usual breakpoint-style debugging inside kernels) and Release builds
> using ComputeCpp, as well as generally allowing any implementation to be
> detected and used (much like find_package(MPI) can find MPI-CH, MS-MPI as
> well as OpenMPI).
>
>
>
> My problem is that even if I have the nicest imported target set up in a
> FindModule.cmake script with components pointing to the various
> implementations (my initial take on the problem), there is no way for me to
> call the ComputeCpp compiler just by linking to an imported library target.
> This was the reason CUDA up until CMake 3.9 used add_cuda_executable()
> function and is the same reason why ComputeCpp uses the add_sycl_to_target()
> function.
>
>
>
> If I would like to raise the bar to the level of CUDA in terms of UX, I’d
> need to patch CMake to being SYCL-aware. It would be much simpler however if
> imported targets had the ability to invoke user-defined scripts (defined in
> the FindModule.cmake script) that is invoked with the supplied parameters.
> Something like:
>
>
>
> # FindLibrary.cmake
>
> set(important „something important”)
>
>
>
> function(add_stuff_to_target TARGET target
>
>  IMPORTANT_VAR var)
>
>   …
>
> endfunction(add_stuff_to_target)
>
>
>
> add_library(Vendor::Library INTERFACE IMPORTED)
>
>
>
> # NOTE: TARGET  is always added as a param to SCRIPT when linked to.
>
> # NOTE 2: SCRIPT is only valid for IMPORTED libraries.
>
> set_target_properties(Vendor::Library PROPERTIES SCRIPT add_stuff_to_target
>
>  SCRIPT_PARAMS IMPORTANT_VAR
> ${important})
>
>
>
> # CMakeLists.txt
>
> find_package(Vendor REQUIRED COMPONENTS Library)
>
>
>
> add_executable(MyProg main.cpp)
>
>
>
> target_link_libraries(MyProg PRIVATE Vendor::Library)
>
>
>
> This (or some similar way) libraries need not necessarily have to patch
> CMake in order to implement features such as:
>
> Qt MOC-ing files
> CUDA ptx compilation
> HLSL/GLSL compilation (this could be an object library that is linked to a
> CUSTOM_SCRIPT enhanced imported library
> XAML compiler invocation
> SYCL force include file generation
> I’m sure there are many more similar use cases
>
>
>
> The function would always receive the target name, from where just about
> everything can be queried, things originating from the FindModule.cmake
> script (counterparts to vars like CMAKE_AUTOMOC) could be passed in as well.
>
>
>
>
>
>
>
> To sum it up: do you see value in lowering the bar to this level in adding
> significant facilities to CMake independently of CMake itself? This way,
> these facilities would be much more agile if updates to them need not wait
> for a new CMake version.
>
>
>
> Cheers,
>
> Máté
>
>
> --
>
> 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 

Re: [cmake-developers] Adding compile and build type tests to CMake/CTest

[Edward Diener]

On 9/18/2017 8:16 AM, Brad King wrote:

On 09/15/2017 09:22 AM, Edward Diener wrote:

A gui environment like Visual Studio does provide
functionality to just compile one or more source files, and it also
provides functionality to just build an executable from one or more
source files without actually running that executable.


Yes.  We just need it to be generated separately from the main build
system so that "Build Solution" or our ALL_BUILD.vcxproj don't try
to build the tests.  Some work will be needed on the CMake side to
do this in a built-in way.

Do you happen to know if/how it is possible to take a .vcxproj with
multiple source files (ClCompile entries) and use MSBuild to compile
just one of the sources from the command-line?  The IDE must do it
somehow with the right-click "Compile" option.  Similarly in Xcode?


I do not know much about MSBuild since I have normally used the IDE.




I would just like to see a built-in
equivalent to testing under CMake which involves only a successful
compilation or not, equivalent to Boost Build's 'compile/compile-fail'
rule and a built-in equivalent to testing which involves only a
successful build or not of a non-build target equivalent to Boost
Build's 'link/link-fail' rule. I think both of the latter are valid
testing methodologies which do not involve an actual run-time test.


Yes, having a built-in solution would be nice.  Currently these can
only be achieved indirectly by writing tests that configure projects
that are not configured by CMake as part of the main project.

BTW, where is the corresponding discussion of this problem on the
Boost side taking place?


When the original announcement from the Boost Steering Committee was 
made a few months back that Boost would be moving to CMake there were 
numerous discussions about converting jam files to CMake and how this 
can be done, largely on the Boost developers mailing list. I brought up 
issues about how to duplicate Boost Build testing under CMake. Since 
then there has been little further discussion about this or indication 
by the Boost Steering Committee how this was to be done, on the 
developers mailing list. One implementation popularly considered is on 
Github as https://github.com/boost-cmake/bcm, but that implementation of 
a pure compile test is a kludge IMO, which led to this discussion here.




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] Custom script invocation from imported target

[Nagy-Egri Máté Ferenc via cmake-developers]

Hi!

I am trying to improve the developer experience of SYCL users for both those 
using triSYCL and ComputeCpp alike. (TL;DR: SYCL is CUDA of OpenCL, triSYCL 
being a non-conforming playground implementation built atop OpenMP, while 
ComputeCpp is the first (and only) conforming GPU-accelerated implementation.) 
Although they are two wildly different implementations, it would come in handy 
to mix the two, having Debug builds rely on triSYCL (for the usual 
breakpoint-style debugging inside kernels) and Release builds using ComputeCpp, 
as well as generally allowing any implementation to be detected and used (much 
like find_package(MPI) can find MPI-CH, MS-MPI as well as OpenMPI).

My problem is that even if I have the nicest imported target set up in a 
FindModule.cmake script with components pointing to the various implementations 
(my initial take on the problem), there is no way for me to call the ComputeCpp 
compiler just by linking to an imported library target. This was the reason 
CUDA up until CMake 3.9 used add_cuda_executable() function and is the same 
reason why ComputeCpp uses the add_sycl_to_target() function.

If I would like to raise the bar to the level of CUDA in terms of UX, I’d need 
to patch CMake to being SYCL-aware. It would be much simpler however if 
imported targets had the ability to invoke user-defined scripts (defined in the 
FindModule.cmake script) that is invoked with the supplied parameters. 
Something like:

# FindLibrary.cmake
set(important „something important”)

function(add_stuff_to_target TARGET target
 IMPORTANT_VAR var)
  …
endfunction(add_stuff_to_target)

add_library(Vendor::Library INTERFACE IMPORTED)

# NOTE: TARGET  is always added as a param to SCRIPT when linked to.
# NOTE 2: SCRIPT is only valid for IMPORTED libraries.
set_target_properties(Vendor::Library PROPERTIES SCRIPT add_stuff_to_target
 SCRIPT_PARAMS IMPORTANT_VAR 
${important})

# CMakeLists.txt
find_package(Vendor REQUIRED COMPONENTS Library)

add_executable(MyProg main.cpp)

target_link_libraries(MyProg PRIVATE Vendor::Library)

This (or some similar way) libraries need not necessarily have to patch CMake 
in order to implement features such as:
- Qt MOC-ing files
- CUDA ptx compilation
- HLSL/GLSL compilation (this could be an object library that is linked to a 
CUSTOM_SCRIPT enhanced imported library
- XAML compiler invocation
- SYCL force include file generation
- I’m sure there are many more similar use cases

The function would always receive the target name, from where just about 
everything can be queried, things originating from the FindModule.cmake script 
(counterparts to vars like CMAKE_AUTOMOC) could be passed in as well.



To sum it up: do you see value in lowering the bar to this level in adding 
significant facilities to CMake independently of CMake itself? This way, these 
facilities would be much more agile if updates to them need not wait for a new 
CMake version.

Cheers,
Máté
-- 

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] Proposal: Support more protoc options in FindProtobuf

[Brad King]

On 09/19/2017 07:50 PM, Peter Mitrano wrote:
> Does this sound reasonable? Would this be something I could contribute?

Yes, see:

  https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst

for instructions.

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] GCC x cmake

[Petr Kmoch]

On Tue, Sep 19, 2017 at 11:34 AM, Ivam Pretti 
wrote:

> I would like to know what are the advantages or difference when compared
>> to GCC compiler.
>>
>>
> I understand from the topic you mean compared to cmake; but the two are
> two different things
> gcc is a compiler
> cmake is a build system that uses compilers
> it'd be more meaningful to say make v cmake...
>
> so there is no comparison... definatly an apples and steak comparison (or
> orange would at least be fruit)
>

I think it's even more accurate to say CMake is not a buildsystem either,
but a *generator* of buildsystems. How it works:

CMake generates a buildsystem (such as Makefiles, build.ninja, a Visual
Studio .sln file). Then a build tool (such as make, ninja, Visual Studio,
XCode) interprets that buildsystem to issue compilation commands. These
commands are executed by a compiler (such as gcc, clang, cl).

I fully agree with comparing GCC to CMake being an apples to steaks
comparison (and I'm stealing that phrase for future use) :-)

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