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

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