[cmake-developers] Revitalize --find-package mode?

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

Hi!

I’m currently struggling with trying to build GNOME projects using meson, but 
depending on CMake-built libraries, either in the wild or inside a package 
manager. I have managed to uncover that the way Meson is trying to invoke CMake

https://github.com/microsoft/vcpkg/issues/6683#issuecomment-533034646

to obtain dependency information is no longer maintained in CMake, or at least 
discouraged for new projects. My queries on the Meson forums did not resonate 
well (in fact they didn’t resonate at all):

https://groups.google.com/forum/#!topic/mesonbuild/OEB0UIlLl0A

Are there any opinions in how to make ends meet? I’m trying to build GIMP on 
Ubuntu LTS releases, which often have outdated packages that cannot be used to 
build GNOME master branches as well as build them natively on Windows using 
Vcpkg ports. The current method Meson tries to use CMake is totally 
Vcpkg-unfriendly. As far as I saw --find-package mode and toolchain failes are 
not friends, even configuring a one-line main.cpp fails due to basic variables 
not being set in --find-package mode.

What specific routes do you see viable?

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

Re: [cmake-developers] cmake-file-api and CTest

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

Hi!

Someone managed to beat me to creating a CTest adapter for the Test Explorer UI 
extension to Visual Studio Code, so instead of writing on from scratch, I’ll 
start contributing to it. There is an „autorun test” property which can be 
triggered when the adapter sees fit. I wanted to create file watchers for the 
executable AND any files the test depends on, based on the REQUIRED_FILES 
property of the test. However, when the REQUIRED_FILES property is set on a 
test and I ask for –show-only=json-v1 ctest.exe fails with exit code 
-1073740791 and outputs nothing. Was this intended?

Cheers,
Máté

Feladó: Nagy-Egri Máté Ferenc
Elküldve: 2019. július 9., kedd 9:41
Címzett: Kyle Edwards; CMake fejlesztők
Tárgy: RE: [cmake-developers] cmake-file-api and CTest

Hi Kyle,

I’ve never contributed to CMake before. I once wanted to enchance the makefile 
generators with batch-mode support and built CMake myself and walked through 
the code in debug mode to see what it does. I identified the entry point where 
I should’ve placed my code, but essential it would’ve require a major rewrite 
of the makefile generators to enable deferred makefile generation. Daunted by 
the amount of work, I figured it was not worth the effort. (It was primarily 
motivated by NMake.)

I’ll try giving the file API a spin and see if I understand the code enough to 
be able to add new queries and extract tests from the internal representation. 
I was hoping to not have to touch CMake itself for this summer project, but it 
seems that’s the first step.

Cheers,
Máté

Feladó: Kyle Edwards
Elküldve: 2019. július 8., hétfő 15:56
Címzett: Nagy-Egri Máté Ferenc; CMake fejlesztők
Tárgy: Re: [cmake-developers] cmake-file-api and CTest

On Sun, 2019-07-07 at 09:04 +, Nagy-Egri Máté Ferenc via cmake-
developers wrote:
> Hi!
> 
> I am trying to cook a CTest back-end to the Test Explorer UI
> extension for VS Code as a summer project and I thought of using the
> new cmake-file-api for it. The docs however are understandably scarce
> and I could not muster how to obtain tests and not targets. Is it
> possible with this initial API design? If not, is my best bet to
> invoke CTest and parse the console output?

FileAPI does not currently list CTest tests, though I agree that this
would be a good thing to have, perhaps for 3.16. Is this something
you'd be willing to help with?

Kyle


-- 

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-developers

Re: [cmake-developers] cmake-file-api and CTest

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

Hi Kyle,

I’ve never contributed to CMake before. I once wanted to enchance the makefile 
generators with batch-mode support and built CMake myself and walked through 
the code in debug mode to see what it does. I identified the entry point where 
I should’ve placed my code, but essential it would’ve require a major rewrite 
of the makefile generators to enable deferred makefile generation. Daunted by 
the amount of work, I figured it was not worth the effort. (It was primarily 
motivated by NMake.)

I’ll try giving the file API a spin and see if I understand the code enough to 
be able to add new queries and extract tests from the internal representation. 
I was hoping to not have to touch CMake itself for this summer project, but it 
seems that’s the first step.

Cheers,
Máté

Feladó: Kyle Edwards
Elküldve: 2019. július 8., hétfő 15:56
Címzett: Nagy-Egri Máté Ferenc; CMake fejlesztők
Tárgy: Re: [cmake-developers] cmake-file-api and CTest

On Sun, 2019-07-07 at 09:04 +, Nagy-Egri Máté Ferenc via cmake-
developers wrote:
> Hi!
> 
> I am trying to cook a CTest back-end to the Test Explorer UI
> extension for VS Code as a summer project and I thought of using the
> new cmake-file-api for it. The docs however are understandably scarce
> and I could not muster how to obtain tests and not targets. Is it
> possible with this initial API design? If not, is my best bet to
> invoke CTest and parse the console output?

FileAPI does not currently list CTest tests, though I agree that this
would be a good thing to have, perhaps for 3.16. Is this something
you'd be willing to help with?

Kyle

-- 

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-developers

[cmake-developers] cmake-file-api and CTest

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

Hi!




I am trying to cook a CTest back-end to the Test Explorer UI extension for VS 
Code as a summer project and I thought of using the new cmake-file-api for it. 
The docs however are understandably scarce and I could not muster how to obtain 
tests and not targets. Is it possible with this initial API design? If not, is 
my best bet to invoke CTest and parse the console output?




Cheers,


Máté




ps.: apologies if this should've gone to CMake Users, but I thought this 
feature is so new there's no end-user knowledge to tap into.
-- 

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-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] Adding compile and build type tests to CMake/CTest

[Nagy-Egri Máté Ferenc via CMake]

Indeed, such a feature would come in handy to test libraries for correctly 
failing on erronous user input.

What amazes me even more is that noone has stepped up yet to create CBench. A 
utility executable for measuring compilation times and capture output of some 
(micro)benchmark instrumentation, either one of its own or some external tool, 
like google/benchmark. Present output either as a table on the console, ASCII 
art or as .xls/.html… you get what I mean.

Has it never bothered anyone enough yet to create quantitative output of a 
build, other than the binary failed/passed kind tests?

Feladó: Robert Ramey
Elküldve: 2017. szeptember 12., kedd 19:12
Címzett: cmake@cmake.org
Tárgy: Re: [CMake] Adding compile and build type tests to CMake/CTest

On 9/4/17 6:40 AM, Edward Diener wrote:
> Boost Build has tests for running an application successfully or not, 
> for compiling one or more source files successfully or not, and for 
> building one or more source files into an exe or not. These tests in 
> Boost Build are the run/run-fail, compile/compile-fail, and 
> link/link-fail rules.
> 
> CMake/CTest has the exact equivalent to the run/run-fail rule in its 
> add_test framework, but there is not add_test equivalent to the other 
> two sets of rules. It sure would be nice, when Boost transitions to 
> using CMake/CTest instead of Boost Build, if CMake/CTest had the 
> equivalent of the other two sets of types of test in its add_test 
> framework.
> 
> Is there any consensus that these other two types of tests might be 
> valuable for CMake/CTest, or any way to make this happen ?
> 

I would like to second this suggestion.  The absence of this feature 
presents a huge obstacle to replicating the functionality of the boost 
build functionality with CMake.  It's amazing to me that after so many 
years CMake doesn't have this functionality already.  It certainly seems 
to me that this would be easy to implement.

I'm aware that suggestions using CMake macros have been proposed.  But 
to the inexperienced user they are not intuitive or easy to understand.

Could we get some response on Edward's suggestion here? It's a serious 
obstacle to implementing support of CMake in Boost libraries.

Robert Ramey

-- 

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

-- 

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

Re: [CMake] Clang for Windows with CMake and Ninja (and Visual Studio)

[Nagy-Egri Máté Ferenc via CMake]

The link error is some error on my setup. The /nologo et al part still stands 
though. Can CMake invoke the Windows binary of Clang correctly?

Feladó: Nagy-Egri Máté Ferenc via CMake
Elküldve: 2017. szeptember 12., kedd 15:01
Címzett: Cmake Mailing List
Tárgy: [CMake] Clang for Windows with CMake and Ninja (and Visual Studio)

Hi!

I am trying to build using the Open Folder feature of VS (with CMake server 
mode integration) with the Windows binary release of Clang. However, when I try 
to build using clang++.exe, it argues about unknown compiler switches

clang++.exe: error: no such file or directory: '/nologo'

while if I use the clang-cl.exe front-end of Clang, it fails saying

LINK : fatal error LNK1104: cannot open file 'gdi32.lib'

Does this both inside VS and in a developer command prompt. My invocation is as 
follows:

cmake -G Ninja -DCMAKE_CXX_COMPILER=C:/Kellekek/LLVM/Clang/5.0/bin/clang++.exe 
C:\Users\Matty\Source\simplecpp\


My questions:

1. Why does CMake give MSVC params to Clang on Windows?
2. Is there a way to let the clang-cl front-end know how to link to system 
libraries?

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

[CMake] Clang for Windows with CMake and Ninja (and Visual Studio)

[Nagy-Egri Máté Ferenc via CMake]

Hi!

I am trying to build using the Open Folder feature of VS (with CMake server 
mode integration) with the Windows binary release of Clang. However, when I try 
to build using clang++.exe, it argues about unknown compiler switches

clang++.exe: error: no such file or directory: '/nologo'

while if I use the clang-cl.exe front-end of Clang, it fails saying

LINK : fatal error LNK1104: cannot open file 'gdi32.lib'

Does this both inside VS and in a developer command prompt. My invocation is as 
follows:

cmake -G Ninja -DCMAKE_CXX_COMPILER=C:/Kellekek/LLVM/Clang/5.0/bin/clang++.exe 
C:\Users\Matty\Source\simplecpp\


My questions:

1. Why does CMake give MSVC params to Clang on Windows?
2. Is there a way to let the clang-cl front-end know how to link to system 
libraries?

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

Re: [cmake-developers] C++ IDE

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

I do not find it to be a joke, rather than being one of the best out there (if 
not THE best).

I tried CLion just 2 weeks ago. It was a nice experience when it came to CMake, 
but it’s C++ IntelliSense capabilities seem to be lacking. (Truth be told, I 
did try with the experimental MSVC support, so I do plan to revisit CLion once 
that is baked.) The thing I did not like about CLion is that it tries to cater 
the click-click way of getting a build ready, but does not go all the way (nor 
even half the way).

I tried getting a build ready of one „src/Main.cpp” and a „inc/Header.hpp” (I 
believe this is the most common source file organization), but I failed to add 
the „target_include_directories” statement through the UI. So, if CLion caters 
those who wish to add source files through the UI, which even prompts for a 
CMake variable to add the source file to, and even follows along the lines of 
changing the CMake script when one relocates files through the UI… then why 
can’t I set something as simple as an include directory through the UI???

I believe the problem CLion got caught in is that it is very hard (if not 
impossible) to wrap a UI around a stateful, imperative language with also 
letting the user edit the CMakeLists.txt file. VS had a much easier job with 
MSBuild (an XML-based build system), but with CMake, it’s much harder. This was 
one of the reasons I suggested roughly a year ago to create an IR for CMake (to 
decouple generators from the front-end, and also facilitate IDE interop).


So all in all, I considered VS to be a nicer, more consistent overall 
experience than the one in CLion. I have not tried Qt Creator yet (I know it 
was among the first to adopt cmake-server), but will do soon, as I will also 
revisit CLion once they call the MSVC experience baked.

ps.: I found it strange that CLion still seems to rely on Codeblock NMake 
Makefiles for both executing a build AND also hooking the IntelliSense 
experience into the IDE. Correct me if I’m wrong, but I thought CLion will be 
the first to adopt cmake-server.
ps2.: Big brother VS is already at executing builds with Ninja by default.
ps3.: once this (link) issue is fixed in relation to the cmake-tools extension, 
I’ll consider VS Code for serious work. It has other nice benefits that big 
brother VS does not.

Feladó: Jean-Michaël Celerier
Elküldve: 2017. augusztus 18., péntek 15:37
Címzett: Nagy-Egri Máté Ferenc
Másolatot kap: CMake Developers
Tárgy: Re: [cmake-developers] C++ IDE

> Visual Studio 2017 has the best C/C++ experience with CMake
IMHO, Visual Studio's CMake integration is a joke in comparison to QtCreator 
and CLion.




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Aug 18, 2017 at 12:04 PM, Nagy-Egri Máté Ferenc via cmake-developers 
<cmake-developers@cmake.org> wrote:
Impressed with VSCode?? If I saw this post anywhere else than the CMake mailing 
list, I’d understand, but VSCode with CMake is horrible. The fact that in 2017 
I have to set include directories, compiler definitions and target paths 
manually to have proper IntelliSense (Code navigation and syntax higlight) is 
absurd.
 
As far as I saw Visual Studio 2017 has the best C/C++ experience with CMake. 
(Google: Visual Studio Open Folder support with CMake)
 
Feladó: Wesley Smith
Elküldve: 2017. augusztus 10., csütörtök 6:38
Címzett: Ivam Pretti
Másolatot kap: cmake-developers@cmake.org
Tárgy: Re: [cmake-developers] C++ IDE
 
I have been really impressed with VSCode.  
 
On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti <ivamprett...@gmail.com> wrote:
Can you recomend an IDE to code in C/C++?

--

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


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMak

Re: [cmake-developers] C++ IDE

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

Impressed with VSCode?? If I saw this post anywhere else than the CMake mailing 
list, I’d understand, but VSCode with CMake is horrible. The fact that in 2017 
I have to set include directories, compiler definitions and target paths 
manually to have proper IntelliSense (Code navigation and syntax higlight) is 
absurd.

As far as I saw Visual Studio 2017 has the best C/C++ experience with CMake. 
(Google: Visual Studio Open Folder support with CMake)

Feladó: Wesley Smith
Elküldve: 2017. augusztus 10., csütörtök 6:38
Címzett: Ivam Pretti
Másolatot kap: cmake-developers@cmake.org
Tárgy: Re: [cmake-developers] C++ IDE

I have been really impressed with VSCode.  

On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti  wrote:
Can you recomend an IDE to code in C/C++?

--

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] CMake Server Mode and USE_FOLDERS

[Nagy-Egri Máté Ferenc via CMake]

I can only speak about VS, which currently neither with the VS nor the Ninja 
generator use the FOLDERS property to lay out the targets inside the Solution 
Explorer. Instead, it maintains the folder structure of the CMake project. This 
was an intentional design decision from their part (at least for the time 
being), due to CMake folks primarily being used to the command line, thus they 
think in therms of the folder structure, not the logical layout of the CMake 
scripts.

There is a tendency though of hooking all CMake notions into the IDE, such as 
CTests show up Test Explorer. Reach out to the VS CMake team and let them know 
that there is such need, perhaps controlled through a switch.

Feladó: Michael Jackson
Elküldve: 2017. július 4., kedd 4:08
Címzett: Cmake Mailing List
Tárgy: [CMake] CMake Server Mode and USE_FOLDERS

I was just exploring in a command line the CMake Server mode in 3.8 (I 
have not tried 3.9 yet) just to see what gets output and I was wondering 
if CMake-Server mode supports "set_property(GLOBAL PROPERTY USE_FOLDERS 
ON)" for any generator? I was specifically using the "ninja" generator 
for my experiments. I suspect not since Ninja itself does not have the 
concept of this but I though I would inquire.

If IDE's that are now relying on CMake-server had this information it 
would allow the IDE to present the project in such a way that the 
developers intended or laid out. I know we put a lot of time into our 
CMake files so that the Visual Studio and Xcode projects are reasonably 
organized when you open them instead of just listing 250 targets.

Thanks for any insights.

Mike Jackson

-- 

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

-- 

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

Re: [cmake-developers] CMake PCH Prototype

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

I just wanted to note that big thumbs up for both the effort and the design. 
Eagerly awaiting the time I can use it in my projects. As soon as it lands, 
I’ll imbue the triSYCL CMake scripts to make use of it.

Sidenote/question: Is it possible for multiple targets to share the same PCH? 
This usage scenario was not apparent to me based on the discussions. triSYCL 
has 100+ single source file targets but all rely on roughly the same set of STL 
and Boost dependencies that never change throughout development.

Feladó: Daniel Pfeifer
Elküldve: 2017. június 18., vasárnap 17:34
Címzett: Julian Landesberger; CMake Developers
Tárgy: [cmake-developers] CMake PCH Prototype

Hi Julian,

I have rebased my old precompiled-headers branch on master and created a 
work-in-progress merge-request here: 
https://gitlab.kitware.com/cmake/cmake/merge_requests/984

Cheers, Daniel


2017-06-15 13:38 GMT+02:00 Julian Landesberger :
Hallo Daniel,
wir hatten uns nach deinem Meetup-Vortrag letzte Woche kurz über die Verwaltung 
von precompiled headers in CMake unterhalten. Du meintest damals, du hättest 
bereits eine Art Prototyp dafür geschrieben, der aber noch nicht an "großen" 
Projekten getestet wurde, und, dass du ihn dafür zur Verfügung stellen könntest.
Ich würde den Prototypen gerne am Simulationscode des Lehrstuhls für 
Computation in Engineering der TU München ausprobieren. Der hat immerhin über 
6000 source- und header-Dateien, ist also kein kompaktes Beispielprojekt mehr.
Würde mich freuen wenn wir da was machen könnten und beste Grüße!
Julian Landesberger


-- 

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] CUDA sample using CMake 3.9

[Nagy-Egri Máté Ferenc via CMake]

Hi!

Can anyone point to a minimalistic sample of how a CUDA application is built 
using the new CMake 3.9 support for CUDA compilation? I am mostly interested in 
promoting similar syntax of building SYCL applications that share a very 
similar compilation model, as far as ComputeCpp is concerned.

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

Re: [cmake-developers] Proposed Feature: automatic search prefixes forfind modules

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

I think it’s a good idea.

Having PackageConfig.cmake files for all projects would be better, but 
unfortunately, many projects don’t support CMake to that extent (or to any 
extent to be precise). I still consume SFML like this, even though the project 
itself builds with CMake, so they could’ve really cook some package config 
files in the past 6 years, but no. Qt most notably is project that builds with 
a 3-rd party tool (qmake), but the Windows installer actually installs proper 
package config files (kudos). GLM when built from github even registers the 
install into the user registry (kudos**2).

Feladó: Chuck Atkins
Elküldve: 2017. május 3., szerda 20:12
Címzett: CMake Developers
Tárgy: [cmake-developers] Proposed Feature: automatic search prefixes forfind 
modules

Brad and I discussed this a few years ago but nothing really came of it.  
Working through several find modules today, I saw many common patterns for this 
and realized it should be pretty easy to implement, so here it is:
Allow the variables ENV{PackageName_ROOT} and PackageName_ROOT to be used as 
initial search prefixes for al find_{file,path,library,program} commands 
executed from within a find module.

https://gitlab.kitware.com/cmake/cmake/merge_requests/796
Specifying the search prefix is a very common pattern, especially when the 
utility is not setup in your path, and prevents the need to explicitly set the 
location of all the various headers and libraries for a module when you can 
just specify a prefix to use.


Thoughts? Good Idea?  Bad idea?  Good, but do it differently?  Undecided?
Thanks
- Chuck

-- 

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] Splitting CMakeLib

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

Hi Egor!

This thread very much resembles my suggestion from two years ago, when I 
proposed there should be an intermediate representation of the CMake scripts so 
generators can be implemented against a stable IR as opposed to bare C++ 
constructs. (Google „CMake IR”)

My main motive too was to give CMake an alternative front-end beside the CMake 
scripts language. I am productive enough with it (not comfortable), but most 
people (even my students at university) have a very hard time mastering it. 
Most abandon CMake at the first possible moment and simply cook build.sh 
scripts for Linux while using Visual Studio click-click project generation 
together with MSBuild (now also available on Linux). IDE tooling will hopefully 
help in that regard.

My first thought was PowerShell, but Python is equally applicable. Having an IR 
instead of C++ API to hook into is vastly simpler, hence my original proposal. 
The CMake server mode tackles a very similar issue, but that solves only part 
of this equation: external tools extracting information from CMakes internal 
machinery. It does not help in injecting information, or outright generate the 
entire process. If CMake were able to consume the same type of JSON it is able 
to dump as an output, such tooling were much easier to implement.

Even though enabling the main executable to consume server mode json and 
execute it is less work than modularizing the entire code base, actually 
refactoring the code in such a way would have collateral benefits. It wouldn’t 
just facilitate the authoring of 3-rd party front-ends, but would also 
facilitate cooking up language services inside IDE-s. If the CMake script 
lexer-parser were available together with server mode, it would enable for much 
more precise IntelliSense capabilities in all IDEs.

I still believe though that having a well defined set of schemas (may them 
represent a script AST or a declarative workflow (or both)) would benefit CMake 
in the long run.

Feladó: Egor Pugin
Elküldve: 2017. május 11., csütörtök 18:55
Címzett: Brad King
Másolatot kap: CMake Developers
Tárgy: Re: [cmake-developers] Splitting CMakeLib

I see, thanks!

I'll ping when something is ready, but do not expect much in the near
future (2-4 months).

On 11 May 2017 at 16:21, Brad King  wrote:
> On 05/10/2017 10:56 AM, Egor Pugin wrote:
>> I'd like to re-use some CMake internal components, but CMakeLib looks too 
>> fat.
>> Is it possible to split it into several libraries? Are such changes
>> welcome to contribute?
>
> Refactoring/organizing/cleanup changes like that would certainly be welcome.
>
>> Some rough plan:
>> 1) Support library (if any stuff)
>> 2) Core library (targets etc.)
>> 3) Generators library
>> 4) CMake syntax library (lexer, parser)
>> 5) Commands implementation library (could be merged with 4)
>>
>> True cmake power is in its generators. It's always possible to rip off
>> all other stuff, but in order to be tied with mainstream and
>> contribute back, I'm asking this.
>
> Stephen Kelly had started work toward separating the code model from the
> language.  The code model should become an independent representation that
> can be input to the generators but be produced independent of the language.
> See cmState for example.  He isn't working on it anymore but left a thread
> some time ago on this list enumerating some future work that could be
> picked up by others (I don't recall which thread though).
>
> -Brad
>



-- 
Egor Pugin
-- 

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

[CMake] Boost 2 & CMake news

[Nagy-Egri Máté Ferenc via CMake]

Does anyone know of the happening around Boost 2 and its possible adoption of 
CMake? I know Boost and CMake have a very long and very sad history, but I 
recall someone reporting on this list that he/she will attend a Boost 2 related 
conference and will again promote the benefits of CMake as opposed to the 
 Boost Build. What is the status of 
the initiative?
-- 

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

Re: [CMake] [Visual Studio] Universal Windows Platform projects

[Nagy-Egri Máté Ferenc via CMake]

I would also very much like to see a tutorial on this. There are just too darn 
many options to set for me to believe CMake could ever get the job done. 
Release notes for Publishing to the store, age rating for my app, can it 
correctly set source types to be DX resources, DX shaders, etc… there are too 
many things I have not even heard about relating to CMake.

I have a feeling that the WindowsStore CMAKE_SYSTEM_NAME started out as a pilot 
project but then did not wish to keep up with the evolution of the Microsoft 
ecosystem. It’s a shame really, because I really did want to prove to collegues 
of mine, that the MVVM model employed by the canonical design pattern of 
Windows Store apps has a 1-to-1 mapping in the Qt ecosystem.

XAML >> QML
events-delegates >> signal-slot

The best choice of a build generator would be CMake. However, not having met 
all the neccessary components, VS project files with the Qt Add-In currently 
seem to be a better choice.

The foundations are very-very similar and I wanted to build a simple 
application that relies on Qt for the Linux build and pure WinRT for the 
Windows build. Also, I would also be very much interested in additions to CMake 
where CTest could take care of Pester tests for PowerShell scripts and as such 
is able to test PS scripts I wrote which load C++/CX Assemblies. (For those who 
do not know of C++/CX, it is managed C++, a language extension that can act as 
a mediator between native C++ and all the .NET family of languages. One may 
wrap FFTW with managed C++ and load the compiled library (referred to as 
Assemblies) from C#, F# or PowerShell even and consume it. The ABI of the .NET 
languages are stable and interoperable.) 


If someone has a working prototype of CMake compiling a simple UWP Store app 
that could actually be published… do not hesitate to share!



Feladó: Adam Rankin-- 

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

Re: [CMake] Visual Studio + Ninja?

[Nagy-Egri Máté Ferenc via CMake]

Short version: no.

Long version: Visual Studio is heavily built around MSBuild as the back-end of 
execution of various tasks. While theoretically it could be done that MSBuild 
only acts as a relay and calls into Ninja scripts, you would lose the entire 
feature set of Solution Explorer, which is quite a large portion of the IDE. 
(Using CMake does preclude using most of it though.) MS is looking into deeper 
CMake integration into their IDE, but the exec back-end will most likely be 
MSBuild.

Should you really want to achieve this, you would need support from both CMake 
side and VS side. You would need to develop an Add-In with a custom project 
type (CMake+Ninja) and hook up most Solution Explorer entries to generate not 
MSBuild but Ninja script portions. And from CMake you would need a generator 
for this mixed generator type. It could be done, but it’s a lot of effort. 
Given the performance of MSBuild (which is not that bad compared to Ninja), the 
benefits would only be substantial in enourmous projects. MS generally looks 
into increasing build throughput by integrating IncrediBuild into their IDE.



Feladó: Robert Dailey
Elküldve: 2016. március 2., szerda 21:45
Címzett: CMake
Tárgy: [CMake] Visual Studio + Ninja?

Right now I am using a toolchain file to setup cmake to build my C++
code against Android NDK. I also have several custom targets for
running 'ant' commands for the java portions.

I can use the Ninja generator to generate the build scripts to make my
builds work fine. However, I'd love to be able to use Visual Studio on
Windows as my IDE. However, there is no "Visual Studio - Ninja"
generator that I can see. Is there a way to make Visual Studio wrap
the Ninja scripts and simply execute them? that way I can use it to
edit code and invoke builds.

Thanks in advance.
-- 

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

-- 

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

Re: [CMake] compiler independent compiler flags

[Nagy-Egri Máté Ferenc via CMake]

Hi Jan,

Unfortunately, I cannot help you in this regard, though I am surprised how 
little attention this question gained. I too feel that CMake could do better 
both in this regard. While ABI detection is very well done, BUILD_TYPE seems to 
be the only compiler agnostic option available. I do not know how to set 
warning levels for eg. in a compiler agnostic manner. Aside from this, there 
are dozens of other options that are common to all C++ compilers and it would 
rock if I need not look up the exact params for all of them.

Sorry I could not help, but I do feel the struggle.

Cheers,
Máté

Feladó:  Jan Hegewald
Elküldve: 2016. február 5., péntek 11:36
Címzett: cmake@cmake.org
Tárgy: [CMake] compiler independent compiler flags

Dear all,
do you know a best practice on how to specify compiler flags without knowing in 
advance which compiler will be used?
Its about Fortran projects, where I e.g. want to explicitly enable the 
preprocessor, or make all default real values 8 byte wide. This could be done 
as such:
if(${CMAKE_Fortran_COMPILER_ID} STREQUAL "Intel")
  set(CMAKE_Fortran_FLAGS "-fpp -r8")
elseif(${CMAKE_Fortran_COMPILER_ID} STREQUAL "GNU")
  set(CMAKE_Fortran_FLAGS "-cpp -fdefault-real-8")
endif()

Cmake has the cmake-compile-features and I though maybe some similar mechanism 
exists for above mentioned compiler switches. So I could say
target_compile_features(mylib PRIVATE f_preprocessor f_real_8)

Thanks for sharing your advise,
Jan


-- 

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

-- 

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

Re: [CMake] CTest integration in Visual Studio TestExplorer

[Nagy-Egri Máté Ferenc via CMake]

Hi Michael,

first of all, let me congratulate you on the integration. Great stuff and much 
apreciated.

I gave your add-in a spin, however it fails to find my unit tests. I set the 
output directory globally in the top-level CMakeLists.txt file as


set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${Build_Root}/bin/${Configuration_Name})

inside my unit-tests’ file I have entries such as

# Adding library target for build
add_executable (STL-Test1-RK4 ${STL_Test1_RK4_BUILD})

…

# Add CTest entry
add_test( ${PROJECT_NAME} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/STL-Test1-RK4 )


I have configured my build to use VS2015 Win64 platform. Because the default is 
to look for x86 targets, I changed the default test platform to be x64 within 
VS, but it still won’t find my tests. Could you give some directions what might 
I be doing wrong?

Cheers,
Máté


Feladó: Stuermer, Michael SP/HZA-ZSEP
Elküldve: 2016. január 22., péntek 12:37
Címzett: cmake@cmake.org
Tárgy: [CMake] CTest integration in Visual Studio TestExplorer

Hello everyone,

picking up the line from Tobias from around a year ago I changed a few things 
in the ctest unittest adapter. It now works for both Visual Studio 2013 and 
2015. 2012 is supported in general but I didn't try it (means: I can install 
it). Merging and pull request for original version will follow (as soon as 
there is time), but I would be really happy if some developers from the 
community could comment on the current state and give some feedback.

I tested it so far with the CMake build and tests and discovering and executing 
the whole lot of 400+ tests runs well so far. Let me know what could/should be 
improved.

You can download the latest version of the extension here:

https://github.com/micst/CTestTestAdapter/blob/micst/CTestTestAdapter.vsix

Check the sources on github here:

https://github.com/micst/CTestTestAdapter

best regards,
Michael


-Original Message-
From: Tobias Becker [mailto:becker.t...@gmail.com] 
Sent: Saturday, November 22, 2014 11:35 PM
Subject: [CMake] CTest integration in Visual Studio TestExplorer

So I tried my luck with creating an extension for Visual Studio that allows you 
to use the Test Explorer to discover and run your CTests.  You can download it 
in the visual studio gallery. Read about it on 
http://thetoeb.de/2014/11/22/ctest-integration-visualstudio/ .

I'd be happy if anyone wanted to give me feedback or contribute on 
https://github.com/toeb/CTestTestAdapter ;)

Sorry for the shameless plug (but hey - its free)


Kind Regards,

Tobias
-- next part --
An HTML attachment was scrubbed...
URL: 


-- 

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

-- 

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

Re: [CMake] Customizing output of ctest command

[Nagy-Egri Máté Ferenc via CMake]

I would also be very much interested how this could be done. There was a thread 
I started a few months ago on a similar topic. I wanted to see the execution 
times of various tests without the initialization part. If my tests could 
output in some form the useful part of their run times, it would be nice if 
CTest could collect them and print them to console.



Feladó: Andrey Pokrovskiy
Elküldve: 2016. január 20., szerda 21:02
Címzett: CMake ML
Tárgy: [CMake] Customizing output of ctest command

Hi,

One of my tests generates a report table (file in text format). I
would like to see its content after each ctest (or make test)
invocation. Is there any way to achieve that?
I noticed that tests targets have ATTACHED_FILES property, though it
looks like it has no effect on ctest run when dashboard is not
configured. I don't need and don't want to setup dashboard, but I
would like to include information that is important to me in ctest
output.

For example:

[...]
Start 33: run_tests
33/33 Test #33: run_tests .   Passed0.06 sec

100% tests passed, 0 tests failed out of 33

Total Test time (real) =   0.28 sec

/* Attached: results.json */
{
"call_site_size": {
"zf_log": "48",
"easylogging++": "376",
"glog": "144",
"spdlog": "352",
"g3log": "360"
}
}
-- 

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

-- 

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

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

[Nagy-Egri Máté Ferenc via CMake]

Hi DJ,

I had the same feeling when I started out with CMake. Tutorials are generally 
of low quality, and the price of the book is steep. I asked a while back if 
there would be a digital version of it, that could come cheaper due to the lack 
of paper and distribution hassle, but Kitware said there is no intent on having 
a digital copy.

CMake however is a fine piece of software (not the best, but it gets the job 
done with a tolerable amount of frustration), and once you have it mastered, 
you can get serious *hit done in a matter of minutes. Even without 
cross-platform, dependency finding is alone worth it, not to mention unit tests 
built in.

As for learning, I would highly suggest reading CMake scripts of other 
projects, as there are some very nice scripts. SFML’s scripts are easy to read 
(though get complicated towards the end), and also some FindModule.cmake 
scripts (FindOpenCL.cmake that ships with CMake starting from version 3.0 is 
nice) are useful. After reading some scripts, cooking up some of your own isn’t 
hard.

Cheers,
Máté




Feladó: DJ
Elküldve: 2015. december 18., péntek 22:03
Címzett: cmake@cmake.org
Tárgy: [CMake] Are the poor reviews of Mastering CMake Justified?

I have only very recently encountered the need to use cmake. It seems 
this need came all at once out of the blue.

It appears to me that there is a general perception that good tutorial 
material is in short supply. I have followed various tutorials that are 
available online and find them less than stellar. I am mostly familiar 
with gnu toolchain stuff. I admit that I am biased here because my own 
work presents zero requirement for cross-platform builds. So far I find 
cmake documentation to be considerably inferior to gnu documentation, 
but that's just me.

This all led me to consider purchasing the book Mastering CMake. 
However, reviews on Amazon are generally very critical of the book. It 
is indeed expensive. Should I bother to shell out for it, or do others 
here share this negative evaluation of it? I don't want to waste my money.

Best,

- Jake -


-- 

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

-- 

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

Re: [CMake] Benchmarking with CMake

[Nagy-Egri Máté Ferenc via CMake]

Thank you all for your resonses,

My use case is that I have a set of executables that function as unit tests. 
Currently I use the return value of the .exe as a means of indicating success, 
though I know there is way to match std::cout against a regex for more complex 
tests. However, the timings of the tests are not always suitable for 
benchmarking, because I only want the timings of a particular part of the 
tests. Their initialization times are comparable to their runtimes. While I 
could tune a parameter so that the init phase is negligable, but then 
benchmarking would take for ages. I want to write benchmark executables 
(similar to unit tests) that write a single number to the console and nothing 
else. Run some command (make bench?, cbench?) which runs, these tests, fetches 
the sole number from the std::cout and prints those numbers as output instead 
of the total run time presented by ctest.

@Peter: I also encountered Google Benchmark. I have already seen it’s output 
and is perfectly fine. I am however a bit reluctant to grab another dependency 
that all my consumers would be advised to install. CMake is a fairly full blown 
suite and I was hoping to find something that could provide similar results.

@Matt: Seems nice. Python is not much a dependency, but VTK is less evident to 
be present on all machines.

@Alexander: I still have to look into this, because information seems a little 
scarce on doing it. It seems to me, that CDash has to be installed somewhere to 
be able visualize the data. Is there a way to generate the HTML-r for local 
consumption instead of submitting somewhere? (Ideally bypassing a local 
installation of CDash)

I know, I have a lot of problems. Ultimately I will choose one of the above, I 
was just looking for the one that is the least painful. I am very reluctant on 
obtaining dependencies. CMake is such a good tool, it seems strange to me that 
no direct benchmarking support has been added yet.

Any ideas?


Feladó: Nagy-Egri Máté Ferenc via CMake
Elküldve: 2015. november 9., hétfő 23:27
Címzett: CMake felhasználók
Tárgy: [CMake] Benchmarking with CMake


Hi!

Can anyone tell me if CMake (or CTest) can be customized in a way to produce 
decent benchmark output? An .xlsx perhaps, or something GnuPlot friendly? I 
have not found any examples of CTest being (ab)used in this way.

Is my feeling correct, that this should be something like CBench?

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

[CMake] Benchmarking with CMake

[Nagy-Egri Máté Ferenc via CMake]

Hi!

Can anyone tell me if CMake (or CTest) can be customized in a way to produce 
decent benchmark output? An .xlsx perhaps, or something GnuPlot friendly? I 
have not found any examples of CTest being (ab)used in this way.

Is my feeling correct, that this should be something like CBench?

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

[CMake] packageConfig mishap

[Nagy-Egri Máté Ferenc via CMake]

Hi!
I'm trying to use the package config file of clFFT (big congrats on providing 
one), but it seems I'm doing something wrong. Without using FindclFFT.cmake, 
CMake fails to find the config files, both on Windows and Ubuntu. On Windows I 
have a registry entry such as:
PS C:\Users\Matty> Get-ItemProperty -Path HKCU:\SOFTWARE\Kitware\CMake\Packages\


clFFT_2.6.1  : C:\Kellekek\AMD\clFFT\2.6.1\CMake
PSPath   : 
Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\SOFTWARE\Kitware\CMake\Packages\
PSParentPath : 
Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\SOFTWARE\Kitware\CMake
PSChildName  : Packages
PSDrive  : HKCU
PSProvider   : Microsoft.PowerShell.Core\Registry

and also on Linux:

mnagy@opteron:~/Build/clFFT_Test/opteron$ cat 
~/.cmake/packages/clFFT_2.6.1.package
/opt/AMD/clFFT/2.6.1/lib64/cmake/clFFT

but every time I configure a project, I get the following error:

mnagy@opteron:~/Build/clFFT_Test/opteron$ cmake -D CMAKE_BUILD_TYPE=Release 
~/Develop/clFFT_Test/
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Warning at CMakeLists.txt:39 (find_package):
  By not providing "FindclFFT.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "clFFT", but
  CMake did not find one.

  Could not find a package configuration file provided by "clFFT" with any of
  the following names:

clFFTConfig.cmake
clfft-config.cmake

  Add the installation prefix of "clFFT" to CMAKE_PREFIX_PATH or set
  "clFFT_DIR" to a directory containing one of the above files.  If "clFFT"
  provides a separate development package or SDK, be sure it has been
  installed.


CMake Warning at CMakeLists.txt:40 (find_package):
  By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "OpenCL", but
  CMake did not find one.

  Could not find a package configuration file provided by "OpenCL" with any
  of the following names:

OpenCLConfig.cmake
opencl-config.cmake

  Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set
  "OpenCL_DIR" to a directory containing one of the above files.  If "OpenCL"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring done
-- Generating done
-- Build files have been written to: /home/mnagy/Build/clFFT_Test/opteron

Without providing CMAKE_PREFIX_PATH on the command-line, the paclage config 
files do not work. What exactly am I doing wrong? According to the CMake wiki

http://www.cmake.org/Wiki/CMake/Tutorials/Package_Registry

it should be working automatically (as is the whole purpose of packages).
-- 

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

Re: [CMake] [cmake-developers] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

@all:


Thank you folks for the input and the active discussion (not shifting into 
flame and troll wars).


@DaveDan:




I agree that JSON looks better. I have no fetish about XML and I could be 
convinced on just about anything in the choice of the IR. The only important 
point is that it SHOULD EXIST and be well defined. Hooking all the generators 
straight into the script interpreter is not good. 




The only reason I intially chose XML and XSD is because they are readily 
available in just about any language. (Take the C++ codegen lib for instance) 
The big difference is that XSD is a widely adopted recommendation. Every lib 
supports it. The moment JSON can provide a schema that is as widely adopted as 
XSD, I have no objection against JSON. I read through 
http://www.w3schools.com/Schema/default.asp in a matter of a few hours and it 
as simple as things can get. But spawning a JSON schema for this project alone 
would feel like being back at square 1.



Even if nothings becomes of this idea, if CMake could manifest such a thing 
(like LLVM is for… just about everything C++ related), it would both distill 
the internals into something easier to comprehend, and at least significantly 
increase interoperability with IDEs and it’s own generators. (Deferred 
generation would be a welcome side-effect. The generators would only be invoked 
once the IR is complete. Whether the generator make use of the global info or 
spawn build invocations and targets on their first encounter is up to the 
generator to decide.)




@Dan:




I don’t quite understand resistance toward MS tech. Windows resides on +80% of 
PCs in the world, CMake already has VS and NMake generators… if there existed 
multiple input languages, I do not understand why one of them couldn’t be a 
native Windows script language.




@Eric:




Thank you for the extensive and thorough answer.




I have not taken a look at Gyp, but will surely do.




As for conditionals and complex scenarios. If the people who encountered such 
barriers could elaborate a little on what their experiences were, maybe design 
could take such cases into consideration from day one.




As for the GUI editor of a project, it has occured to me (and others too) that 
such a tool would be darn useful. If it were a seperate tool, I’d still use it 
just about every day, but you are correct that this feature would be best 
embedded into the IDE. I am actively engaged with the folk at the Visual C++ 
team who are looking for a way to hook CMake into the IDE. So, if all goes well 
it might even happen.-- 

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

[cmake-developers] CMake IR

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

Dear CMake devs/users,


I wanted to ask your opinion on something that has been troubling me since… 
well, ever since I started using CMake. I have not found a single person alive 
who would have said:


“The script language of CMake is nice, intuitive and productive. Authoring 
scripts is easy, and writing custom macros is not difficult either.”


There are gazillions of scripting languages one could have chosen for CMake 
(Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to 
reuse existing skills, or learn one that is useful elsewhere, not just in terms 
of CMake. These languages have a lot of thought put into them. They are 
superior to CMake’s own in just about every regard.


I came up with an idea presented here: http://1drv.ms/1MsufbF



Enhancements such a change could bring about:

The big selling point would be the ability to introduce arbitrary front-ends to 
CMake, not just CMakelists.txt. Every developer could choose an input language 
that suits their project/needs/skills.


(It would also ease the custom implementations of cmake.exe itself in any 
language, but that is just a side-effect.)


It would modularize the internals of CMake in a cleaner fashion


Facilitate the introduction of new languages understood by CMake (such as work 
put into C# and Swift currently)


Would allow for configure-time validating of compiler-specific options


Use deferred makefile generation by default (making the implementation of tools 
like Cotire for precompiled headers trivial to implement, as well NMake batch 
mode, or detecting multiple/cyclic linkage, by making use of global information 
about the build process)


Many features could automatically be reused by all generators. (Imagine Swift, 
and Fortran libraries being compiled as NuGet packages and publishing them 
without any hassle on user side, or having to implement anything in the XCode 
generator.)


SIGNIFICANTLY increase interoperability with other tools. Implementing GUI 
front-ends (such as in CLion, or Visual Studio (work in progress)) are orders 
of magnitude simpler by generating a stateless IR, as opposed to generating a 
stateful script.



While it is a refactor of the entire toolchain, it is something that could be 
done incrementally, with the existing parts functioning normally.


I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake 
users I’ve met say they are “happy” CMake users. The learning curve is steep, 
and the skills gained are not reusable. CMake could gain even greater momentum 
(not by ditching, but) by offering alternate input languages with entities 
(classes, functions, macros, etc.) that feel natural in the given context.


Initial feedback in my vicinity was favorable, even those with zealous CMake 
opposition aggreed this were something awesome to pull off (though they 
expressed their disbelief in Kitware and the community approving such a radical 
change). This mail along with the document only intends to get the ball rolling 
and hopefully manifest in something similar, starting with CMake 4.0 perhaps.


Eagerly await the rolling ball.


With all due respect,

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] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

@Domagoj:


“In addition to it feeling like working with (or fighting against) an ugly 
crossover between a C preprocessor and a shell script from 1979, an 
increasingly 
big source of frustration is its rigidness and limitation of 'only one 
toolset/compiler per project'.”


 I couldn’t have put it any better myself.


Indeed, I recently had the idea of writing a Windows Store XAML application to 
give a GUI frontend to TagLib, just as an excercise and give it a jump start in 
August on my vacation when I want to do something productive. I started 
collecting the dependencies and everything, and came across… CMake has Windows 
Store support, but how on Earth am I going to build x86/x64/ARM targets from 
one VS solution? I was reading the docs a while and said to mysef “ah, f*ck it, 
no CMake has nothing to do here.” It is very annoying that CMake has these 
limitation at it’s very core that would take months and months to rule out. I 
can imagine Android being even more painful in this regard. CMake really could 
do a whole lot better in this.


@Nicolas:


Yes, these tools indeed have been working for the past few decades. Others also 
suggested why don’t I generate CMakelists.txt instead?


The problem is that the current limitations of CMake all originate from the way 
the workflow is organized. Multi-configuration makefiles are trivial to 
implement if you do them by hand. All targets append the architecture after 
their name (app-x86, app-x64, lib-x86, etc.) and there were all-x86 and all-x64 
targets, and there were the usual “all” target that references all-x86, 
all-x64. In CMake the workflow is baked into selecting an architecture at the 
earliest points in the configuration process and stores it as a global variable 
(state!) which then shoots all multi-configuration generators in the knee.


Yes, it is possible to remove this limitation from CMake, but it would take 
roughly a year. Holding onto this limitation alone just because it is 
historically the way how CMake has been designed immediately rules it out from 
~75% of application development going on in the world in the future (mobile app 
devel), which is funny because building cross-platform mobile apps is the 
future, and this is just the market that could benefit of CMake the most.


@Bill:


I am a member, I just tried sending using the same mail using the “secret CC” 
option. It seems it did not work.


@David:


Maybe some convincing and positive feedback can do the trick. I mostly live my 
life on Windows, so most technologies and tools relate to Windows, but all the 
HPC clusters I use are linux, hence the need for CMake. My initial research 
builded down to this:


Learn from the ‘competition’


Identify the portable properties of building a C++ application (mostly from 
CMake) and define an XML Schema.


Create the Schema of a chosen compiler


Implementing everything in C++


Initially do not bother with a front-end. Using the Schema, Visual Studio can 
provide Intellisense based on the .xsd file. This is sufficient for dev 
pourposes.


Using this open-source lib, getting a parser/deserializer and datastructure for 
use in C++ is as easy as 1-2-3.


Use the aforementioned lib to get a datastructure and serializer using the 
MSBuild Schema.


Almost done. Just wrap the Schemas of the IR into neat C++ classes. Tadaaa: C++ 
front-end.


Wrap the C++ classes with C++/CX for use with Powershell. Tadaaa: Powershell 
front-end.


Implement everything in PS (just for kicks)


PS alread understands the [xml] type and can read/write and process it. 
Validation can be used from PSCX.


Transform the data read into MSBuild’s own. (Somewhat blindly, because there 
are no neat classes available in the MSBuild Schema format)


Amost done. Write PS5 classes around the Schema entities. Tadaaa: PS front-end.



Future work:

Make it better


Implement other generators after the all too convenient, XML based MSBuild.


Add Unit Test Schemas


Add packaging Schemas (Nuget is again XML based with XSD Schema, trivial to 
implement)


Enhance package support to be able to fetch dependencies from git and build (a 
la Cargo), have installation method similar to CMake packages, etc.



If the entire build’s information is available as an iterable C++ tree-like 
datastructure, how hard can it be to implement generators like Ninja? (Not 
trivial, but not hard either.) If there is a clear Schema of valid options for 
a specific feature, so many things simplify. Again, imagine automatic fetching 
of dependencies from multiple repositories even. Nuget, GitHub, .deb, you name 
it!


And I haven’t even mentioned things like remote builds and what not… all new 
features could be introduced as a seperate Schema with it’s respective options, 
and if the user references the schema in the IR, and the generator supports it, 
it is done. Imagine distributed builds similar to Incredibuild, but with CMake. 
Nothing is needed, but the user define a pool of machines, 

[CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

Dear CMake devs/users,


I wanted to ask your opinion on something that has been troubling me since… 
well, ever since I started using CMake. I have not found a single person alive 
who would have said:


“The script language of CMake is nice, intuitive and productive. Authoring 
scripts is easy, and writing custom macros is not difficult either.”


There are gazillions of scripting languages one could have chosen for CMake 
(Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to 
reuse existing skills, or learn one that is useful elsewhere, not just in terms 
of CMake. These languages have a lot of thought put into them. They are 
superior to CMake’s own in just about every regard.


I came up with an idea presented here: http://1drv.ms/1MsufbF



Enhancements such a change could bring about:

The big selling point would be the ability to introduce arbitrary front-ends to 
CMake, not just CMakelists.txt. Every developer could choose an input language 
that suits their project/needs/skills.


(It would also ease the custom implementations of cmake.exe itself in any 
language, but that is just a side-effect.)


It would modularize the internals of CMake in a cleaner fashion


Facilitate the introduction of new languages understood by CMake (such as work 
put into C# and Swift currently)


Would allow for configure-time validating of compiler-specific options


Use deferred makefile generation by default (making the implementation of tools 
like Cotire for precompiled headers trivial to implement, as well NMake batch 
mode, or detecting multiple/cyclic linkage, by making use of global information 
about the build process)


Many features could automatically be reused by all generators. (Imagine Swift, 
and Fortran libraries being compiled as NuGet packages and publishing them 
without any hassle on user side, or having to implement anything in the XCode 
generator.)


SIGNIFICANTLY increase interoperability with other tools. Implementing GUI 
front-ends (such as in CLion, or Visual Studio (work in progress)) are orders 
of magnitude simpler by generating a stateless IR, as opposed to generating a 
stateful script.



While it is a refactor of the entire toolchain, it is something that could be 
done incrementally, with the existing parts functioning normally.


I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake 
users I’ve met say they are “happy” CMake users. The learning curve is steep, 
and the skills gained are not reusable. CMake could gain even greater momentum 
(not by ditching, but) by offering alternate input languages with entities 
(classes, functions, macros, etc.) that feel natural in the given context.


Initial feedback in my vicinity was favorable, even those with zealous CMake 
opposition aggreed this were something awesome to pull off (though they 
expressed their disbelief in Kitware and the community approving such a radical 
change). This mail along with the document only intends to get the ball rolling 
and hopefully manifest in something similar, starting with CMake 4.0 perhaps.


Eagerly await the rolling ball.


With all due respect,

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

Re: [CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

How many people have I asked? We are a group of 5, and have several fellows who 
have drifted off to companies each with their respective dev teams of 5-15 
people. General tendency is that everywhere, there is 1 CMake guru, the rest 
would be better off not touching the scripts, because they do more harm than 
good.


I can believe that someone coming from the autotools or GNU Make find CMake to 
be a salvation. But someone being used to Visual Studio’s Solution Explorer 
(and things generally working out-of-the-box) finds hand authoring scripts in a 
unique language that’s been documented only 2 months ago… Don’t get me wrong, I 
am an admin and spend a considerable amount of time scripting in various 
languages. It’s not the fact that I have to touch scripts. It’s the fact that 
doing so is a pain.


The reason I suggested this as a CMake 4.0 feature is because I am the 11th 
person out of 10 who actually “likes” CMake a bit and cares for it. I’d rather 
empower a tool I use on a daily basis than spawn an alternative and spend half 
my life trying to winning the world over. As is the case with operating 
systems, they have accumulated so much code, there is no point in trying to 
write a new one, rather than fixing the ones that exist. Every respectable 
cross-platform project uses CMake and I have no intention of going against 
that. I’ve neither the resources (time mostly) to do that, neither do I like 
the fact of spawning ‘yet another build system’ when nothing prevents from 
enhancing one that is almost perfect.


With enough feedback like yours, I might just brew something similar in a few 
years time (on the expense of my free time). I could do something just like the 
author of Invoke-Build did and brew something that only I in the entire world 
would use, even though that in some sense Invoke-Build is far better than GNU 
Make or NMake in its foundations (being a processor of inter-dependent jobs, 
and nothing else).


I understand your concern with people trying to hijack a community project and 
alter it to their personal ideals. However the fact that there are people 
fighting a war for CMake-izing Boost 2.0, and the fact that Boost 1.x failed 
two attempts at doing so is because the Boost developers were reluctant to pick 
up CMake as a build system, even though it is superior to Boost Build in every 
aspect. That too, is a build system used only in Boost, and nowhere else in the 
world. (I even had an email discussion with the authors of such an attempt. He 
handed all the working scripts to the devs, all they should’ve do was type 
cmake.exe ../src, but they did not.) One of the reasons these attempts failed 
was because of the Boost dev’s love for their ‘own child’ (Boost Build). The 
other is that CMake is unfriendly for devs. It is better than many others, but 
worse than many others. When it works, it’s great. But getting it to work is 
not always as easy as one might like.


I had an idea I felt would benefit the community (the CMake community that is), 
I thought I’d share it as an idea.


ps.: I also had an email encounter with the dev of Invoke-Build about cooking 
up an Invoke-Build back-end to CMake. He had no idea CMake exists, but because 
he needed a scriptable (from Powershell that is) build system, he cooked up one 
of his own. If CMake had a PS front-end, maybe a whole bunch of people pick it 
up who don’t even know it exists because they live outside the cross-platform 
world.






Feladó: Raymond Wan
Elküldve: ‎szerda‎, ‎2015‎. ‎július‎ ‎29‎. ‎11‎:‎01
Címzett: Nagy-Egri Máté Ferenc
Másolat: cmake@cmake.org





Hi Máté,


On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote:
 I wanted to ask your opinion on something that has been troubling me since…
 well, ever since I started using CMake. I have not found a single person
 alive who would have said:

 “The script language of CMake is nice, intuitive and productive. Authoring
 scripts is easy, and writing custom macros is not difficult either.”


I'm not much of an expert wih CMake but when someone says I have not
found a single person alive..., I would usually counter by asking how
many people you've asked?  :-)


 Initial feedback in my vicinity was favorable, even those with zealous CMake
 opposition aggreed this were something awesome to pull off (though they
 expressed their disbelief in Kitware and the community approving such a
 radical change). This mail along with the document only intends to get the
 ball rolling and hopefully manifest in something similar, starting with
 CMake 4.0 perhaps.


I for one am quite happy with CMake.  We can point fingers at
technology (i.e., which programming language is better or worse), but
in the end, it's really the community support (IMHO).  And if I'm
stuck with CMake, I can usually find answers to most of my problems on
this e-mail list or by searching Google.

If you want to refactor CMake along these lines:

 There are gazillions of scripting 

Re: [CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

Hi Nico,




thank you for the idea. That idea occured to me too, trying to generate the 
CMakelists.txt script from the desired front-end. Having taken a deep dive into 
XML schemas, hardcore people even criticise W3C XML Schemas for not having a 
mathematical foundation which make it difficult to reason about backward 
compatibility of change to the schema. Using the CMake script, a stateful, 
imperative script language as an intermediate introduces even more threats, 
than using a not so well defined, but at least stateless datastructure like XML.




Seeing that people want this idea as a seperate project more than a part of 
CMake, I thought of:

defining the XML Schema of building a C++ application


defining the XML Schema of a particluar compiler toolchain


write a front-end in a script language of choice


write a generator for a back-end of choice


provide a prototype of a CMakelists.txt  XML front-end as a proof-of-concept





That way CMakelists.txt files could be used in a completeley alternate 
toolchain.





Feladó: Nicolas Desprès
Elküldve: ‎szerda‎, ‎2015‎. ‎július‎ ‎29‎. ‎13‎:‎43
Címzett: Nagy-Egri Máté Ferenc
Másolat: cmake@cmake.org





Hi Máté,



One way of doing would be to write a tool using whatever language you like, 
reading an input script written in whatever language you like, that generates 
cmake code. In such case, the modification to cmake would be smaller but not 
that simple.




You can see this thread from the archive for further details: 
http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html




Cheers,

Nico






On Wed, Jul 29, 2015 at 9:49 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote:




Dear CMake devs/users,




I wanted to ask your opinion on something that has been troubling me since… 
well, ever since I started using CMake. I have not found a single person alive 
who would have said:




“The script language of CMake is nice, intuitive and productive. Authoring 
scripts is easy, and writing custom macros is not difficult either.”




There are gazillions of scripting languages one could have chosen for CMake 
(Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to 
reuse existing skills, or learn one that is useful elsewhere, not just in terms 
of CMake. These languages have a lot of thought put into them. They are 
superior to CMake’s own in just about every regard.




I came up with an idea presented here: http://1drv.ms/1MsufbF





Enhancements such a change could bring about:

The big selling point would be the ability to introduce arbitrary front-ends to 
CMake, not just CMakelists.txt. Every developer could choose an input language 
that suits their project/needs/skills.


(It would also ease the custom implementations of cmake.exe itself in any 
language, but that is just a side-effect.)


It would modularize the internals of CMake in a cleaner fashion


Facilitate the introduction of new languages understood by CMake (such as work 
put into C# and Swift currently)


Would allow for configure-time validating of compiler-specific options


Use deferred makefile generation by default (making the implementation of tools 
like Cotire for precompiled headers trivial to implement, as well NMake batch 
mode, or detecting multiple/cyclic linkage, by making use of global information 
about the build process)


Many features could automatically be reused by all generators. (Imagine Swift, 
and Fortran libraries being compiled as NuGet packages and publishing them 
without any hassle on user side, or having to implement anything in the XCode 
generator.)


SIGNIFICANTLY increase interoperability with other tools. Implementing GUI 
front-ends (such as in CLion, or Visual Studio (work in progress)) are orders 
of magnitude simpler by generating a stateless IR, as opposed to generating a 
stateful script.





While it is a refactor of the entire toolchain, it is something that could be 
done incrementally, with the existing parts functioning normally.




I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake 
users I’ve met say they are “happy” CMake users. The learning curve is steep, 
and the skills gained are not reusable. CMake could gain even greater momentum 
(not by ditching, but) by offering alternate input languages with entities 
(classes, functions, macros, etc.) that feel natural in the given context.




Initial feedback in my vicinity was favorable, even those with zealous CMake 
opposition aggreed this were something awesome to pull off (though they 
expressed their disbelief in Kitware and the community approving such a radical 
change). This mail along with the document only intends to get the ball rolling 
and hopefully manifest in something similar, starting with CMake 4.0 perhaps.




Eagerly await the rolling ball.




With all due respect,

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

Re: [CMake] Rerun CMake partially in Visual Studio

[Nagy-Egri Máté Ferenc via CMake]

May I ask what you mean by ‘editors’? Do you mean GUI editors to managing CMake 
projects?


Máté






Feladó: Bill Hoffman
Elküldve: ‎csütörtök‎, ‎2015‎. ‎július‎ ‎23‎. ‎16‎:‎38
Címzett: cmake@cmake.org





On 7/23/2015 8:45 AM, David Cole via CMake wrote:
 Nope.

 CMake has no way of knowing whether you have logic in the lower level
 CMakeLists file which affects later included projects, or which might
 even possibly affect global (top level project) CMakeCache settings.
 Without adding facilities to track such interconnections, the entire
 tree from the top level down must be re-processed to figure out what
 to generate.
That said, there is some work going on that might actually do this in 
the future.  Stephen Kelley is working on being able to save state and 
tell which parts have been touched.  This would be used for editors but 
would be useful for this type of thing as well.

-Bill


-- 
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
-- 

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-- 

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

Re: [CMake] output of add_custom_command as target in Makefile

[Nagy-Egri Máté Ferenc via CMake]

You’re doing it all wrong. You do not name source files as make targets, but 
the target name (or project name, I have no idea, because it rarely makes sense 
to name them differently). Try simply “foo” or “custom-command-target”. You 
would never say “make foo.cpp”, not even in an ordinary GNU Make script.






Feladó: Dave Yost
Elküldve: ‎péntek‎, ‎2015‎. ‎június‎ ‎12‎. ‎2‎:‎00
Címzett: cmake@cmake.org





In this example, how do I get

   make foo.cc

to work?






0 Thu 16:56:19 yost DaveBook ~/p/c++/cmake/custom-command-target

369 Z% bundle CMakeLists.txt genFoo

#!/usr/bin/env unbundle

# See http://yost.com/computers/bundle/

 CMakeLists.txt

cmake_minimum_required(VERSION 3.3.0)




project(custom-command-target)







add_custom_command (

  OUTPUT  foo.cc

  COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo  foo.cc

  )




add_executable (foo foo.cc)




 genFoo

#!/bin/bash




echo 

int main() {

  return 0;

}



0 Thu 16:56:23 yost DaveBook ~/p/c++/cmake/custom-command-target

370 Z% cd build

0 Thu 16:56:36 yost DaveBook ~/p/c++/cmake/custom-command-target/build

371 Z% cmake ..

-- Configuring done

-- Generating done

-- Build files have been written to: 
/Users/yost/p/c++/cmake/custom-command-target/build

0 Thu 16:56:41 yost DaveBook ~/p/c++/cmake/custom-command-target/build

372 Z% make clean  

0 Thu 16:56:45 yost DaveBook ~/p/c++/cmake/custom-command-target/build

373 Z% make foo.cc 

make: *** No rule to make target 'foo.cc'.  Stop.

2 Thu 16:56:49 yost DaveBook ~/p/c++/cmake/custom-command-target/build

374 Z%-- 

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

Re: [CMake] Visual Studio Project System Extensibilty

[Nagy-Egri Máté Ferenc via CMake]

I’m curious too, but I think that it would be easier to use a fixed format for 
project representation, such as the suggested CPS, and have it generate a CMake 
file if an update is needed.


CMake generally lacks any kind of structure, users are generally free to roam 
about the script language. Qt Creator is doing a similar thing. You have a .pro 
file that is maintained by the IDE, and this .pro file is translated to a QMake 
script, which then translates to a native build system. Such a project could 
start off impementing the translation from CPS to a strictly formatted, 
auto-generated CMake script that only covers the features of the IDE. Once that 
is done, the next few steps can be taken to extend it’s capabilities by adding 
new switches, levers and buttons to the Properties section of the 
Solution/Project entities.


While it does not strictly relate, I would suggest people take a visit here:


http://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7752684-add-cmake-support


Visual Studio Code is a promising new IDE that is completely cross-platform and 
already has pilot support for brand new stuff, such as Rust language support. 
It is a new IDE (that currently looks more like a code editor, as far as C++ is 
concerned), and user input greatly influences the course of action from the 
developers POV. The last patch issued took 2 months and adds ~300 bug fixes and 
feature requests, most originating from uservoice.com.


Please take a moment and up-vote CMake support. Most likely on all platform it 
would rely on the newly open-sourced MSBuild system.


Nontheless, it would be a great win for CMake, if an IDE picked up GUI editing 
of projects that translate to CMake automatically. Either by Visual Studio Code 
picking up support, or if someone took the time and implemented CMake project 
for old-school VS through CPS.


Cheers,

Máté


ps.: David, great job on the VS Add-In for CMake. We love it!






Feladó: David Golub
Elküldve: ‎hétfő‎, ‎2015‎. ‎június‎ ‎8‎. ‎0‎:‎27
Címzett: 'Alexey Petruchik', cmake@cmake.org






Probably doable but still a lot of work.  It took me about a year over my 
nights and weekends to implement CMake Tools for Visual Studio, which provides 
syntax highlighting and IntelliSense for CMake but no project system (yet).

 

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Alexey Petruchik
Sent: Sunday, June 07, 2015 1:45 PM
To: cmake@cmake.org
Subject: [CMake] Visual Studio Project System Extensibilty

 



Microsoft recently announced Project System Extensibility in Visual Studio 2015.


 


http://blogs.msdn.com/b/visualstudio/archive/2015/06/02/introducing-the-project-system-extensibility-sdk-preview.aspx


 


Just curious if this can be used to let Visual Studio directly open CMake 
projects?-- 

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

Re: [CMake] FindModules.cmake quality + Kitware proposition

[Nagy-Egri Máté Ferenc via CMake]

Auto-generating things seems like a good idea, as most CMake scripting feels 
like boilerplate. The majority of the projects do the same things, so it only 
makes sense to try getting some automation working. Perhaps it might go all the 
way to obtaining sources if not found on the computer, similar to what Cargo 
does with Rust.


As for the bountysource.com page, it is a good initiative. Perhaps a link to it 
on the CMake website would be useful.


Cheers,

Máté





Feladó: cmake@cmake.org
Elküldve: ‎csütörtök‎, ‎2015‎. ‎május‎ ‎14‎. ‎21‎:‎24
Címzett: cmake@cmake.org





On 14-May-15 14:01, Nagy-Egri Máté Ferenc via CMake wrote:



This is more of a remark, or something to get the ball rolling, rather than 
anything else.




I recently came across various FindModule.cmake files (FindOpenCL, FindOpenGL, 
FindGLEW, FindGLM, FindSFML) as a sideeffect of a project I am developing, but 
have had my share with quite a few others (FindQt, RustCMake, FindOpenAL, 
FindBoost, …). My overall impression is that the quality of these modules is 
highly fluctuating to say the least. While generally the FindModules shipping 
with CMake as built-in scripts are usable, there is a fair amount of room for 
improvement.




FindGLEW.cmake for eg. is terrible. I have never imagined that such a widely 
used library has a 7 line FindModule script. On Windows it is practically 
useless.




As for nearly all other FindModule scripts, nearly none of them use 
target_include_libraries() that would allow for end-users of the scripts to not 
have to worry about include directories.




Some projects strive at being cross-platform, but compiling them on Windows 
(mostly the GNU projects that aim on being Windows friendly) is massive pain. 
libJPEG to name just one provides nmake makefiles that are capable of producing 
Visual Studio 2010 project files at best (huuraay), and have undocumented 
external dependencies. These projects (and their users) cry out for CMake 
support.




Here is a proposition to consider:
This sounds like a workaround for the existing problems. What we really need to 
do to solve this issue completely is to use automatically generated Find-like 
modules - PackageConfig.cmake. See: 
http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages
 




Kitware generally has the philosphy with CMake being: do it yourself or hire us 
to do it. While on a corporate basis this is a legitimate approach, I as a poor 
academic fellow do not have 10.000$ to spare for a feature I so wish, neither 
do I have the time to educate myself in the internal ways of CMake to 
contribute. So all I do is hack, hack, hack all day.




The Chocolatey project (a package manager for Windows) recently won a massive 
Kickstarter campaign that aimed solely increasing the overall quality of the 
project. With this campaign they aimed on growing from an ‘interesting idea’ to 
begin ‘mainstream’. With the money they won, they hired full time package 
moderators, developed automated scripts of facilitating authoring, wrote 
tutorials, created templates, and even managed to get the ball rolling with 
OneGet (Powershell 5.0 package manager manager) to adopt Chocolatey as the 
first supported public repo.




I would suggest Kitware start a similar community funded project to increase 
the overall quality of the software. While I do not have 10 grands to buy a 
feature, I do have 10 dollars pocket money to contribute (as do MANY others).




As several levels of goals, the stock FindModules scripts could be brought to a 
homogenous quality, identical naming conventions (no more MYLIB_INC_DIR, 
MYLIB_INCLUDE_DIRS, MyLib_INCLUDE_DIR), high quality templates for new 
adopters, make the CMake Guide freely available online (epub, pdf, docx, 
whatever), convert 10 GNU projects to CMake, convert 50 GNU projects to CMake, 
create Snappy back-end of CPack, or my personal favorite (the feature I do not 
have 10.000 dollars for) is NMake batch mode support for multicore build, etc.




There are so many places CMake itself can be improved, and so many users who 
really should be adopting, but have not started due to lacking man power. 
(These are the projects that would benefit the most from a freely available 
tutorial, because truth be told: writing capable, high-quality CMake scripts is 
no easy task.)




If I were a charmismatic spokesperson I’d say: I RAISE 10 DOLLARS, WHO’S WITH 
ME?! But because I’m not, I’ll just leave it here as a suggestion.




Ideas?

Have you seen https://www.bountysource.com/ ?

Ruslo-- 

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

[CMake] FindModules.cmake quality + Kitware proposition

[Nagy-Egri Máté Ferenc via CMake]

This is more of a remark, or something to get the ball rolling, rather than 
anything else.


I recently came across various FindModule.cmake files (FindOpenCL, FindOpenGL, 
FindGLEW, FindGLM, FindSFML) as a sideeffect of a project I am developing, but 
have had my share with quite a few others (FindQt, RustCMake, FindOpenAL, 
FindBoost, …). My overall impression is that the quality of these modules is 
highly fluctuating to say the least. While generally the FindModules shipping 
with CMake as built-in scripts are usable, there is a fair amount of room for 
improvement.


FindGLEW.cmake for eg. is terrible. I have never imagined that such a widely 
used library has a 7 line FindModule script. On Windows it is practically 
useless.


As for nearly all other FindModule scripts, nearly none of them use 
target_include_libraries() that would allow for end-users of the scripts to not 
have to worry about include directories.


Some projects strive at being cross-platform, but compiling them on Windows 
(mostly the GNU projects that aim on being Windows friendly) is massive pain. 
libJPEG to name just one provides nmake makefiles that are capable of producing 
Visual Studio 2010 project files at best (huuraay), and have undocumented 
external dependencies. These projects (and their users) cry out for CMake 
support.


Here is a proposition to consider:


Kitware generally has the philosphy with CMake being: do it yourself or hire us 
to do it. While on a corporate basis this is a legitimate approach, I as a poor 
academic fellow do not have 10.000$ to spare for a feature I so wish, neither 
do I have the time to educate myself in the internal ways of CMake to 
contribute. So all I do is hack, hack, hack all day.


The Chocolatey project (a package manager for Windows) recently won a massive 
Kickstarter campaign that aimed solely increasing the overall quality of the 
project. With this campaign they aimed on growing from an ‘interesting idea’ to 
begin ‘mainstream’. With the money they won, they hired full time package 
moderators, developed automated scripts of facilitating authoring, wrote 
tutorials, created templates, and even managed to get the ball rolling with 
OneGet (Powershell 5.0 package manager manager) to adopt Chocolatey as the 
first supported public repo.


I would suggest Kitware start a similar community funded project to increase 
the overall quality of the software. While I do not have 10 grands to buy a 
feature, I do have 10 dollars pocket money to contribute (as do MANY others).


As several levels of goals, the stock FindModules scripts could be brought to a 
homogenous quality, identical naming conventions (no more MYLIB_INC_DIR, 
MYLIB_INCLUDE_DIRS, MyLib_INCLUDE_DIR), high quality templates for new 
adopters, make the CMake Guide freely available online (epub, pdf, docx, 
whatever), convert 10 GNU projects to CMake, convert 50 GNU projects to CMake, 
create Snappy back-end of CPack, or my personal favorite (the feature I do not 
have 10.000 dollars for) is NMake batch mode support for multicore build, etc.


There are so many places CMake itself can be improved, and so many users who 
really should be adopting, but have not started due to lacking man power. 
(These are the projects that would benefit the most from a freely available 
tutorial, because truth be told: writing capable, high-quality CMake scripts is 
no easy task.)


If I were a charmismatic spokesperson I’d say: I RAISE 10 DOLLARS, WHO’S WITH 
ME?! But because I’m not, I’ll just leave it here as a suggestion.


Ideas?-- 

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

Re: [CMake] C++Now / BoostCon / Boost 2.0

[Nagy-Egri Máté Ferenc via CMake]

I wish you good luck on promoting CMake for Boost.


Generally, I find the Boost libraries to be of good quality. However, the 
reason I fear depending on Boost in any of my projects is the aggravation to 
get various versions to build. Applications that depend on Boost and are 
shipped as a binary, usually depend a way outdated version, and getting 
Boost to build… I gave it 2 tries, sufficiently remote in time for me to forget 
the pain it caused me in my previous attempts. Configuring and building Boost 
on Windows is a nightmare. I was relieved when I found that there is a project 
about converting Boost to CMake, but as you have said (and as the author 
explained to me) the project was not welcomed. I do not wish to cause the same 
pain for my users (and myself).


Boost Build is just too different from anything out there, it depends on 
software that is not used by anything other than Boost. It makes no sense in 
sticking to it, when from all I’ve seen CMake is superior in all regards. 
Taking into account that there is CTest/CDash/CPack accompanying it, it seems 
outright crazy to stik to Boost Build.


Cheers,

Máté






Feladó: Robert Ramey
Elküldve: ‎kedd‎, ‎2015‎. ‎április‎ ‎28‎. ‎14‎:‎47
Címzett: cmake@cmake.org





I will be giving a presentation at C++Now
http://cppnow.org 
https://cppnow2015.sched.org

all things boost - which will touch upon CMake/CTest/CDash.  I have
recommended CMake... for boost - like projects and would like to see it more
widely accepted. http://rrsd.com/blincubator.com/tools_cmak/ I'm aware that
in the past there was a large effort to switch boost to CMake from Boost
Build which ended in failure.

For Boost 2.0 

https://cppnow2015.sched.org/event/d66a14e9cc28cffbf446b1fd2c3f4696#.VT-AV87_Suc

 I will promote the idea of boost libraries being less tightly coupled. 
Part of will be to propose that library authors be permitted to select their
own build/test system.  Testing of Boost would be just the union of the
testing of all the individual libraries.  Here are a few observations
regarding CMake as it might relate to Boost.

a) In the CMake section of the incubator page, I've advocated creating a
library subdirectory named CMake which includes the cake scripts. The source
files or not in this directory.  The scripts contain relative path names to
source files in the directory.  This permits the CMake scripts to not be
sprinkled all over the directory structure but rather in one place.  I've
used this and found it to work very well.

b) I would like to see testing of boost libraries distributed to library
users/testers and others, and have their test results posted on a library
dashboard.  This would provide a number of advantages.  So I would like to
be able to recommend CTest/CDash.  I have made this setup work - but it
doesn't just work.  I would like to see:

The CTest/CDash system has a sort of elaborate setup of experimental,
nightly, etc. which ties certain test names to different test frequencies. 
This is too complex.  Basically all we need is experimental which I would
more likely call on demand.  This is what users need.  Download a library,
build it, run test suite and post results.  

It's great that you guys run the public dashboard and I would like to
encourage boost libraries developers to use it.  I would like to see a few
cosmetic changes but the idea is close to what I would like to see for
Boost.

I did meet a couple of you at CPPCon last september. If any of you expect go
to C++Now please contact me with any information and/or advice you think
might be useful to me.

Robert Ramey 



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/C-Now-BoostCon-Boost-2-0-tp7590405.html
Sent from the CMake mailing list archive at Nabble.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:
http://public.kitware.com/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:

Re: [CMake] Invoke-Build support

[Nagy-Egri Máté Ferenc via CMake]

I wasn’t hoping for much enthusiasm, but at least some feedback would be 
welcome. Am I making any sense here? Would such work be completely useless? I 
figured a crossplatform make language could make use of a script-friendly 
back-end to facilitate automated building for multiple platforms.






Feladó: cmake@cmake.org
Elküldve: ‎szombat‎, ‎2014‎. ‎december‎ ‎13‎. ‎21‎:‎28
Címzett: cmake@cmake.org





Hi!




Being a CMake user for some time, I have come across the issue of parallel 
builds still being problem with no trivial solution. the NMake back-end does 
not have batch support, which is said to be non-trivial, while the ninja 
generator did tend to fail some builds for me too, when I gave it a spin not 
too long ago (few months). MSBuild.exe seems to do the job, yet some argued 
that if one does not have access to the IDE itself (I do not exactly know that 
is possible to have cl.exe but not MSBuild.exe) then it is not feasable.




I have started using PowerShell recently (to move out of my comfort zone, which 
is C++ and GPGPU), and instantly fell in love. I was looking for scriptable PS 
build systems, and found PSake and Invoke-Build. The former I did not take a 
deep look into, but the latter seems like a very nice project, with a fairly 
straight-forward syntax (as far as the makefile goes), as well as parallel 
capable back-end. The simplicity of the makefile, along with the power of .NET 
and all the built-in scripting fun of PS, I’d guess it might be the simplest 
back-end of CMake yet, if it were supported.




I am very enthusiastic with a very limited amount of time I could dedicate to 
such work, but I thought I’d ask you folks if you see any added value in case 
such a back-end existed? With the chocolatey repository for Windows (in case 
you’ve never heard of it, google first hit gives you the answer) boasting a 
successful Kickstarter funding to raise it to a new level, I believe all 
package maintainers would benefit from a scriptable make system in PS.




I have not looked at CMake source code, but just how much effort would it take 
to fork CMake and create a back-end for Invoke-Build? I have already contacted 
Invoke-Build’s developer, and while he never had to use CMake during his work, 
he is willing to take on the effort from IB’s side if some feature were missing 
to make ends meet.




Best regards,

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

[CMake] Invoke-Build support

[Nagy-Egri Máté Ferenc via CMake]

Hi!


Being a CMake user for some time, I have come across the issue of parallel 
builds still being problem with no trivial solution. the NMake back-end does 
not have batch support, which is said to be non-trivial, while the ninja 
generator did tend to fail some builds for me too, when I gave it a spin not 
too long ago (few months). MSBuild.exe seems to do the job, yet some argued 
that if one does not have access to the IDE itself (I do not exactly know that 
is possible to have cl.exe but not MSBuild.exe) then it is not feasable.


I have started using PowerShell recently (to move out of my comfort zone, which 
is C++ and GPGPU), and instantly fell in love. I was looking for scriptable PS 
build systems, and found PSake and Invoke-Build. The former I did not take a 
deep look into, but the latter seems like a very nice project, with a fairly 
straight-forward syntax (as far as the makefile goes), as well as parallel 
capable back-end. The simplicity of the makefile, along with the power of .NET 
and all the built-in scripting fun of PS, I’d guess it might be the simplest 
back-end of CMake yet, if it were supported.


I am very enthusiastic with a very limited amount of time I could dedicate to 
such work, but I thought I’d ask you folks if you see any added value in case 
such a back-end existed? With the chocolatey repository for Windows (in case 
you’ve never heard of it, google first hit gives you the answer) boasting a 
successful Kickstarter funding to raise it to a new level, I believe all 
package maintainers would benefit from a scriptable make system in PS.


I have not looked at CMake source code, but just how much effort would it take 
to fork CMake and create a back-end for Invoke-Build? I have already contacted 
Invoke-Build’s developer, and while he never had to use CMake during his work, 
he is willing to take on the effort from IB’s side if some feature were missing 
to make ends meet.


Best regards,

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