CMake Support

[bretbrownjr]

So don't hate me, but my current org doesn't have Meson or python anywhere near low enough in the dependency graph to make this project adoptable for anything but experiments.

We'll need to add CMake support, Makefile support, raw ninja support, or some sort of self-bootstrap (autotools?) for building cps-config for it to be useful in that codebase.

I would consider this to be an "adoption hurdle" for cps-config for a significant portion of the C and C++ ecosystem, at least until it becomes popular enough to warrant inclusion in "bootstrap" base images the way things like bash, perl, and Makefile tend to be.

[dcbaker]

So don't hate me

No hate :)

I have the opposite problem. CMake is not in my teams current build process (and there has been a lot of resistance to it), we have Meson, autotools, and cargo.

I really don't want to use autotools, and don't really want to Rewrite in Rust™ :)

One solution, which may be more short term, I have is that there is a pure C99 implementation of Meson called Muon, which is capable of building cps-config now (I made a few small changes to the Meson build to handle this). It can be boostrapped with just a C compiler, bash, and optionally pkg-config.

I also have an implementation of Meson in C++ that I've been working on for a few years, but I never seem to have time to work on it anymore...

Id also like someday to have #23, which for projects using Meson (like Muon and Meson++) it would be a big advantage to have Meson.

So. That leaves me with the following idea. Can we for the short term have just Meson, once we get things further along (a week or two, hopefully) and feel that we've mostly implemented the spec, discuss adding CMake support in addition to the Meson support?

I would consider this to be an "adoption hurdle" for cps-config for a significant portion of the C and C++ ecosystem, at least until it becomes popular enough to warrant inclusion in "bootstrap" base images the way things like bash, perl, and Makefile tend to be.

In the open source world Meson seems to be replacing autotools at various paces, so I'd assume it will end up in base images eventually.

soapbox ahead: Everyone has the eldritch horror that is perl in their images, but no one has python despite the high use and popularity of the latter, and the near universal distaste for the former, and this always confuses me.

[bretbrownjr]

So. That leaves me with the following idea. Can we for the short term have just Meson, once we get things further along (a week or two, hopefully) and feel that we've mostly implemented the spec, discuss adding CMake support in addition to the Meson support?

I think this makes sense. When the project structure and test structure seem settled, we can circle back, add some CMake, and wire up some additional container-based regression tests.

In the open source world Meson seems to be replacing autotools at various paces, so I'd assume it will end up in base images eventually.

Maybe? I'm hoping CPS takes off, people start packaging things more, and then a lot of this becomes moot to a large degree, though low level utilities like this will definitely want to be sensitive to their transitive build dependencies. Bootstrapping from a shell script and make (like CMake and autotools projects do) is appropriate.

soapbox ahead: Everyone has the eldritch horror that is perl in their images, but no one has python despite the high use and popularity of the latter, and the near universal distaste for the former, and this always confuses me.

Just because you said something:

• Perl got there first to some degree, fair or not
• Perl 5 scripts (and bash for that matter) can be expected to work well going forward while python expects you to keep updating things, especially if you go back to the python2 to python3 split
• There are like five supported pythons if you count supported minor versions; sufficient python adoption means having all five installed

I actually like python a lot, personally, but the second two points to make it hard to add pythons (plural) to my base system image (we have a large integrated codebase). For what it's worth, I hate even having perl in our base image. I'd get rid of it if I could. It's much better to have all tools in the build graph and start from almost nothing... like a gcc and bash and maybe Makefile.

[ChrisThrasher]

I think it would be wise to use a more popular build system like CMake or even Makefiles/Ninja. It encourages contribution to use tools that are already widely used in the C++ world. Let's not let our employer's proclivities have too strong of an impact on what decision is made. The C++ world is much bigger than any single organization.

[bretbrownjr]

I'm OK supporting more than one build system as long as we at least have periodic CI checks to support each build system.

[dcbaker]

For one, I'm a Meson developer, so using Meson is my prerogative as much as the communities I work in (where CMake is basically not used, and Autotools is king, with Meson growing in popularity), I'm eating my own dog food, or so to speak.

But more importantly I don't think there's a problem with having two build systems once we get to the point we aren't regularly adding or removing files from the project (which, I think we're pretty much at), and we have options for making what needs to be shared between the two build system (like version information) fairly painless.

And very importantly, if we do develop a re-usable libcps then we're going to have interest in supporting build systems beyond CMake anyway, because I will want to be able to use libcps as a Meson subproject, and it seems like the whole universe ends up with a BUILD.bazel file in their repo.

[tylerjw]

I think that comment was likely directed at much at Bret's comments on bootstrapping and Python as it was a Meson. I think there is plenty of work building this thing out without spending too much on whatever the build tool is for now. I'm all for using Meson as you seem to understand it well and it seems to work well enough.

[bretbrownjr]

Oh. I agree. I'll say something first, but I'll come in with a CMake PR at some point.

I expect we need to get the basic design of cps-config nailed down more first. In particular, I expect the design to evolve a bit if (when?) we need to start supporting multithreading, JSON output, and querying modes that don't look like what pkgconf currently supports.

I'm mostly productive with Meson now. Its VS Code integration has a lot of rough edges, but falling back to the CLI works for now.

[dcbaker]

@bretbrownjr, I'd be happy to pass on issues you have with the vscode integration to the maintainers of that project :)