meson or generic ninja support?

[René J.V. Bertin]

Hi,

I'm tinkering with a project that configures using meson and builds using ninja. Is there anything in (the works for KDevelop) that allows to import such projects properly? FWIW I see that meson generates a compile_commands.json script, and it is invoked as a sort of cross-over between configure and cmake (e.g. --prefix=$prefix but -Doption=value for build options).

Thanks,
R.

[Kevin Funk]

Post by René J.V. Bertin
Hi,
I'm tinkering with a project that configures using meson and builds using
ninja. Is there anything in (the works for KDevelop) that allows to import
such projects properly? FWIW I see that meson generates a
compile_commands.json script, and it is invoked as a sort of cross-over
between configure and cmake (e.g. --prefix=$prefix but -Doption=value for
build options).

No support and no work on that planned.

The CMake support itself relies heavily on having a compile_commands.json
around [1] -- I'm sure you could at least factor out this functionality into a
generic project manager plugin.

But the author of Meson once send us a bug report where he suggested to
implement Meson support:
https://bugs.kde.org/show_bug.cgi?id=343935

With Meson getting more and more popular (at least that's my impression) that
might be a good junior task.

Regards,
Kevin


[1] See kdevelop.git:projectmanagers/cmake/cmakeimportjsonjob.cpp

Post by René J.V. Bertin
Thanks,
R.

[René J.V. Bertin]

Post by Kevin Funk
The CMake support itself relies heavily on having a compile_commands.json

I know, that's why I mentioned its existence.

Post by Kevin Funk
With Meson getting more and more popular (at least that's my impression) that
might be a good junior task.

Indeed - I do not (yet) have enough incentive to start refactoring the CMake plugin myself.

Cheers,
R.

[Aleix Pol]

Post by René J.V. Bertin

Post by Kevin Funk
The CMake support itself relies heavily on having a compile_commands.json

I know, that's why I mentioned its existence.

Post by Kevin Funk
With Meson getting more and more popular (at least that's my impression) that
might be a good junior task.

Indeed - I do not (yet) have enough incentive to start refactoring the CMake plugin myself.

Of course not. You should start a meson plugin, not refactor the cmake one.

Aleix

[René J.V. Bertin]

Post by Aleix Pol
Of course not. You should start a meson plugin, not refactor the cmake one.

Frankly, I don't know (and don't have much incentive to find out) what's better/easier, strip the unneeded parts from the cmake plugin or start something completely from scratch.

I've seen only 1 aspect for now where meson is very different from both configure and cmake: you cannot reinvoke it in an already configured build tree. Instead, you have to use the mesonconf executable, which doesn't have exactly the same calling signature.

[Kevin Funk]

Post by René J.V. Bertin

Post by Aleix Pol
Of course not. You should start a meson plugin, not refactor the cmake one.

Frankly, I don't know (and don't have much incentive to find out) what's
better/easier, strip the unneeded parts from the cmake plugin or start
something completely from scratch.

The compile_command.json parser should be factored out. The file format is
build system agnostic. A couple of different build systems actually support
generating these files (CMake, QBS, <a couple of hand-written scripts>, ...).

For the rest, you'd still need a new plugin for Meson though.

Regards,
Kevin

Post by René J.V. Bertin
I've seen only 1 aspect for now where meson is very different from both
configure and cmake: you cannot reinvoke it in an already configured build
tree. Instead, you have to use the mesonconf executable, which doesn't have
exactly the same calling signature.

[Axel Kellermann]

I'd be willing to help out with this, but I'd also need some guidance by someone
with more experience with kdevelop and project manager plugins. Up till now I've
only done some minor bugfixing concerning cmake integration. So I have a hunch,
but not a clear idea, what meson integration actually encompasses.

With the little experience I have, I imagine we have to have
1) A configure job that runs meson/mesonconf
2) UI elements for setting up projects and their parameters
3) A build job (relying on ninja and the content of compile_commands.json)
4) A parse job to check for syntactical correctness of meson build scripts
5) Some glue code to react to output of meson jobs (OutputView etc.)

Is that - at least to some degree - correct? If not, could someone please
outline what has to be done and give me some pointers where to look for similar
stuff in the kdevelop source tree?
Also, would it be a valid first step to do integration without implementing 4?
Technically that's not really necessary for properly setting up meson projects,
right?

Regards,
Axel

Post by Kevin Funk

Post by René J.V. Bertin

Post by Aleix Pol
Of course not. You should start a meson plugin, not refactor the cmake one.

Frankly, I don't know (and don't have much incentive to find out) what's
better/easier, strip the unneeded parts from the cmake plugin or start
something completely from scratch.

The compile_command.json parser should be factored out. The file format is
build system agnostic. A couple of different build systems actually support
generating these files (CMake, QBS, <a couple of hand-written scripts>, ...).
For the rest, you'd still need a new plugin for Meson though.
Regards,
Kevin

Post by René J.V. Bertin
I've seen only 1 aspect for now where meson is very different from both
configure and cmake: you cannot reinvoke it in an already configured build
tree. Instead, you have to use the mesonconf executable, which doesn't have
exactly the same calling signature.

[Aleix Pol]

Post by Axel Kellermann
I'd be willing to help out with this, but I'd also need some guidance by someone
with more experience with kdevelop and project manager plugins. Up till now I've
only done some minor bugfixing concerning cmake integration. So I have a hunch,
but not a clear idea, what meson integration actually encompasses.
With the little experience I have, I imagine we have to have
1) A configure job that runs meson/mesonconf
2) UI elements for setting up projects and their parameters
3) A build job (relying on ninja and the content of compile_commands.json)
4) A parse job to check for syntactical correctness of meson build scripts
5) Some glue code to react to output of meson jobs (OutputView etc.)
Is that - at least to some degree - correct? If not, could someone please
outline what has to be done and give me some pointers where to look for similar
stuff in the kdevelop source tree?
Also, would it be a valid first step to do integration without implementing 4?
Technically that's not really necessary for properly setting up meson projects,
right?
Regards,
Axel

Post by Kevin Funk

Post by René J.V. Bertin

Post by Aleix Pol
Of course not. You should start a meson plugin, not refactor the cmake one.

Frankly, I don't know (and don't have much incentive to find out) what's
better/easier, strip the unneeded parts from the cmake plugin or start
something completely from scratch.

The compile_command.json parser should be factored out. The file format is
build system agnostic. A couple of different build systems actually support
generating these files (CMake, QBS, <a couple of hand-written scripts>, ...).
For the rest, you'd still need a new plugin for Meson though.
Regards,
Kevin

Post by René J.V. Bertin
I've seen only 1 aspect for now where meson is very different from both
configure and cmake: you cannot reinvoke it in an already configured build
tree. Instead, you have to use the mesonconf executable, which doesn't have
exactly the same calling signature.

If you are interested I can write a proof of concept in the next few days.

Aleix

[Kevin Funk]

Post by Aleix Pol

Post by Axel Kellermann
I'd be willing to help out with this, but I'd also need some guidance by
someone with more experience with kdevelop and project manager plugins.
Up till now I've only done some minor bugfixing concerning cmake
integration. So I have a hunch, but not a clear idea, what meson
integration actually encompasses.
With the little experience I have, I imagine we have to have
1) A configure job that runs meson/mesonconf
2) UI elements for setting up projects and their parameters
3) A build job (relying on ninja and the content of compile_commands.json)
4) A parse job to check for syntactical correctness of meson build scripts
5) Some glue code to react to output of meson jobs (OutputView etc.)
Is that - at least to some degree - correct? If not, could someone please
outline what has to be done and give me some pointers where to look for
similar stuff in the kdevelop source tree?
Also, would it be a valid first step to do integration without
implementing 4? Technically that's not really necessary for properly
setting up meson projects, right?
Regards,
Axel

Post by Kevin Funk

Post by René J.V. Bertin

Post by Aleix Pol
Of course not. You should start a meson plugin, not refactor the cmake one.

Frankly, I don't know (and don't have much incentive to find out) what's
better/easier, strip the unneeded parts from the cmake plugin or start
something completely from scratch.

The compile_command.json parser should be factored out. The file format is
build system agnostic. A couple of different build systems actually support
generating these files (CMake, QBS, <a couple of hand-written scripts>, ...).
For the rest, you'd still need a new plugin for Meson though.
Regards,
Kevin

Post by René J.V. Bertin
I've seen only 1 aspect for now where meson is very different from both
configure and cmake: you cannot reinvoke it in an already configured build
tree. Instead, you have to use the mesonconf executable, which doesn't have
exactly the same calling signature.

If you are interested I can write a proof of concept in the next few days.

@Axel: Best to get in touch with apol in #kdevelop on IRC @ Freenode.

More information:
https://www.kdevelop.org/contribute-kdevelop

You talked about similar functionality in the KDevelop source tree -- have a
look at the cmake or qmake manager:
plugins/cmake* and plugins/qmake*

Regards,
Kevin

Post by Aleix Pol
Aleix

[Axel Kellermann]

So your suggestion is that you write a poc and I help/take over fleshing it out?
If that's a good way for you to go about it, I'm in.

As Kevin suggested, I'll have a look at the cmake and qmake plugins in the
meanwhile.

Axel

Post by Aleix Pol
If you are interested I can write a proof of concept in the next few days.
Aleix

[Aleix Pol]

Post by Axel Kellermann
So your suggestion is that you write a poc and I help/take over fleshing it out?
If that's a good way for you to go about it, I'm in.
As Kevin suggested, I'll have a look at the cmake and qmake plugins in the
meanwhile.
Axel

Post by Aleix Pol
If you are interested I can write a proof of concept in the next few days.
Aleix

Hi Axel,
I just pushed a meson branch to kdevelop you can use to start getting
it rolling.

It has the barebones of how it should look like but I didn't test it.
https://commits.kde.org/kdevelop/9ac4e855ca8272f25ce469ad351660ebdf4bbc24

Hope this helps!
Aleix

[Axel Kellermann]

Thanks, I'll have a look. Can I contact you directly via email if I have
questions, or do you prefer the mailing list or IRC?

Post by Aleix Pol

Post by Axel Kellermann
So your suggestion is that you write a poc and I help/take over fleshing it out?
If that's a good way for you to go about it, I'm in.
As Kevin suggested, I'll have a look at the cmake and qmake plugins in the
meanwhile.
Axel

Post by Aleix Pol
If you are interested I can write a proof of concept in the next few days.
Aleix

Hi Axel,
I just pushed a meson branch to kdevelop you can use to start getting
it rolling.
It has the barebones of how it should look like but I didn't test it.
https://commits.kde.org/kdevelop/9ac4e855ca8272f25ce469ad351660ebdf4bbc24
Hope this helps!
Aleix

[Aleix Pol]

Post by Axel Kellermann
Thanks, I'll have a look. Can I contact you directly via email if I have
questions, or do you prefer the mailing list or IRC?

Post by Aleix Pol

Post by Axel Kellermann
So your suggestion is that you write a poc and I help/take over fleshing it out?
If that's a good way for you to go about it, I'm in.
As Kevin suggested, I'll have a look at the cmake and qmake plugins in the
meanwhile.
Axel

Post by Aleix Pol
If you are interested I can write a proof of concept in the next few days.
Aleix

Hi Axel,
I just pushed a meson branch to kdevelop you can use to start getting
it rolling.
It has the barebones of how it should look like but I didn't test it.
https://commits.kde.org/kdevelop/9ac4e855ca8272f25ce469ad351660ebdf4bbc24
Hope this helps!
Aleix

Sure, whatever you prefer.

Aleix

[Kevin Funk]

Post by Axel Kellermann
Thanks, I'll have a look. Can I contact you directly via email if I have
questions, or do you prefer the mailing list or IRC?

Heya,

just got reminded about Meson since someone is now looking at implementing
support for Bazel...

IRC is preferred for discussing implementation details and the like.

Did you have any chance at looking at the meson branch and driving it further,
Axel?

Regards,
Kevin

Post by Axel Kellermann

Post by Aleix Pol

Post by Axel Kellermann
So your suggestion is that you write a poc and I help/take over fleshing
it out? If that's a good way for you to go about it, I'm in.
As Kevin suggested, I'll have a look at the cmake and qmake plugins in the
meanwhile.
Axel

Post by Aleix Pol
If you are interested I can write a proof of concept in the next few days.
Aleix

Hi Axel,
I just pushed a meson branch to kdevelop you can use to start getting
it rolling.
It has the barebones of how it should look like but I didn't test it.
https://commits.kde.org/kdevelop/9ac4e855ca8272f25ce469ad351660ebdf4bbc24
Hope this helps!
Aleix

[Axel Kellermann]

Post by Kevin Funk

Post by Axel Kellermann
Thanks, I'll have a look. Can I contact you directly via email if I have
questions, or do you prefer the mailing list or IRC?

Heya,
just got reminded about Meson since someone is now looking at implementing
support for Bazel...
IRC is preferred for discussing implementation details and the like.
Did you have any chance at looking at the meson branch and driving it further,
Axel?

I fixed some little issues that prevented compilation on my machine and tried to
wrap my head around the prototype, but then life and work got in the way big
time. So no real progress, sorry. If the prototype in the meson branch is useful
for Bazel implementation, go ahead and base your work upon it. If I find time to
work on meson again, I'll work around this.

Regards,
Axel