[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Supporting the CMake file API in the project/build plugin ?
From:       Waqar Ahmed <waqar.17a () gmail ! com>
Date:       2023-09-08 8:24:56
Message-ID: CAPesRH7h_pGqebJ1OSUSBTEhN_hpWndf_d3aCBqjNpreWOfXBA () mail ! gmail ! com
[Download RAW message or body]

> not sure about that, if it would work like now, you would open the build
dir.

In that way, yes it can work.

On Fri, Sep 8, 2023 at 1:03 PM <christoph@cullmann.io> wrote:
>
> On 2023-09-08 08:59, Waqar Ahmed wrote:
> > I think with cmake, things are not going to be as simple as with git.
> > With git, we just invoke the command, get the files and we are done.
> > With CMake things are a bit more complex, we first need to figure out
> > which build directory to be used and probably provide the user a way
> > to select one and there is a protocol for making requests to cmake and
> > getting responses by re-running cmake. Thus, in my opinion, it would
> > be better to let a dedicated plugin handle this. That plugin can write
> > out the project file and project plugin will automatically detect
> > that.
>
> Hi,
>
> not sure about that, if it would work like now, you would open the build
> dir.
>
> There one CMake run with the file api will tell you all stuff.
>
> Just like ATM you can open the generated project in the build dir.
>
> Greetings
> Christoph
>
> >
> > On Thu, Sep 7, 2023 at 11:44 PM <christoph@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.
> >>
> >> Greetings
> >> Christoph
> >>
> >> >
> >> > Thanks
> >> > Alex
[prev in list] [next in list] [prev in thread] [next in thread]