Supporting the CMake file API in the project/build plugin ?

[Alexander Neundorf]

On Donnerstag, 16. November 2023 08:20:53 CET christoph at cullmann.io wrote:
> On 2023-11-15 23:09, Alexander Neundorf wrote:
> > Hi,
> > 
> > On Donnerstag, 7. September 2023 20:44:07 CET christoph at cullmann.io
> > 
> > wrote:
> >> On 2023-09-06 23:32, Alexander Neundorf wrote:
> >> > Hi,
> >> > 
> >> > currently cmake can generate a kate project file, and then, when kate
> >> > opens
> >> > some file in the buildtree, e.g. the project file, the kate project
> >> > plugin reads
> >> > the project file and populates the list of files and the build targets.
> >> > With cmake 3.27 this has been marked officially as obsolete (even
> >> > though the
> >> > kate project generator gained some features in cmake 3.27).
> >> > 
> >> > Nevertheless, medium term it would be better if kate would use the
> >> > cmake file
> >> > API.
> >> > What would that mean ?
> >> > kate could search the CMakeCache.txt for CMAKE_PROGRAM, which contains
> >> > the
> >> > path to the cmake executable which generated this buildtree.
> >> > Then kate would write some simple json file into the build tree, and
> >> > then rerun
> >> > cmake on that buildtree.
> >> > cmake will see the file kate has written, and generate a json file
> >> > which
> >> > contains the source directory, the list of targets, the source files
> >> > for each
> >> > target.
> >> > With this information kate could:
> >> > - use that list of source files as project files, or use the git/svn
> >> > support in
> >> > kate to get all files which are in the source directory
> >> > - get  the list of targets and generate a build target for each of
> >> > them. Those
> >> > could be executed by running cmake (so it would automatically work for
> >> > any
> >> > build tree, whether it is ninja, make, or msvc): cmake --build
> >> > <buildir> --
> >> > config <Config> --target <target>
> >> > 
> >> > What do you suggest how this would fit into the project- and
> >> > build-plugins ?
> >> > I guess the session support is not related ?
> >> 
> >> Hi,
> >> 
> >> thanks for taking a look at that!
> >> 
> >> I think that would fit into the project plugin as another
> >> auto-discovery
> >> mode,
> >> like we have it for the various version control systems.
> >> 
> >> There we execute the git/.../... commands.
> > 
> > I've got a first version working locally here (still Qt5 based).
> > So I'll clone on gitlab and create a merge request ?
> 
> Hi,
> 
> Great ;)
> 
> Yes, or put it to some work/xxx branch in the
> main repo, that makes it even easier to try.

it's here now:
https://invent.kde.org/utilities/kate/-/commit/
54b4b88d3cb470b4226f4ac91ea54d99c0b8eb59[1]
I haven't actually tried to build it against the KF6 version of kate yet, building against Qt6 
worked.

Basically it works, it creates the project, with build rules for all targets in all build 
configurations, the source files taken from the cmake files and the correct source dir. It 
also creates a compile_commands.json and copies it to thr source dir.

I'm not very happy with the usability.
If the user opens a CMakeCache.txt (or any other file in the build tree), it automatically 
creates a kate project automatically, similar to git and svn.

This is a bit hard to discover, since usually users don't open files in the buildtree.
If the user has opened a file in the source tree before, and git/svn auto projects are 
enabled, no cmake project will be created, i.e. no build commands.

Should I add an explicit entry like "Open CMake build tree" or something like this in the 
project menu ?
I also wonder whether it should optionally populate the project files from the git/svn 
repos, instead of using the files from the CMakeLists.txt.

Any comments ?

Alex


--------
[1] https://invent.kde.org/utilities/kate/-/commit/
54b4b88d3cb470b4226f4ac91ea54d99c0b8eb59
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20231120/e985c3d3/attachment.htm>