Skip to content

Meson integration #5

Open
Open
@meator

Description

@meator

Hello. As I've mentioned in #4, I have an interest in integrating the Meson build system into libcppgenerate. I am working on a project managed by Meson. My project indirectly depends on libcppgenerate. I wish to have all my dependencies managed by Meson to make use of its powerful Wrap dependency system. If I achieve my goal of having all my project's dependencies managed by Meson, the user of my project wouldn't have to have any of its dependencies installed on their system, Meson would be able to download and compile them seamlessly.

I am offering you to port the current CMake system into Meson. I will understand if you reject this offer, because this has pretty major drawbacks, but if you are interested in Meson and its features, I can collaborate and provide advice.

Ditching CMake would be a large breaking change, so the only plausible way to have official support for Meson in libcppgenerate would be to provide both CMake and Meson in libcppgenerate. This would double the maintenance burden for the build system. A deprecation process for the CMake build system could be instated, providing a smooth transition for dependent projects. This would lead to even more work though.

Some advantages of Meson include cleaner build definition syntax, better IDE support (Meson generates compile_commands.json by default), enabling/disabling sanitizers and stldebug with a single standard flag, faster configure and build times (the improvements, if any, will likely be negligible for a project of this size; I have also done no benchmarks), better logs/verbose output, superior cross compilation support and more.

An alternative solution (which I find more plausible) is to provide a Meson build system externally. People like me write Meson build systems for CMake (or other) projects and then contribute them into mesonbuild/wrapdb (which integrates with Meson's Wrap dependency system).

This would require no changes to the current codebase/no additional work from you rm5248 (under normal circumstances).

I have already began this work (see mesonbuild/wrapdb#1956). I've hit a few roadblocks though. They are not the fault of libcppgenerate, they are a result of the difference between how CMake and Meson handles things.

There are some rather small changes that could be made to libcppgenerate which would greatly simplify adding Meson support. But to repeat myself, this is not a bug in libcppgenerate, so I'll understand if you are happy with the current (fully functional) system.

The change in question is to add a output directory argument to all generator executables (specifically tests/generate-class1.cpp, tests/generate-namespace-class.cpp, tests/generate-class-with-method.cpp, tests/generate-imperative-math.cpp and tests/generate-class-with-default-values.cpp).

I am willing to provide a pull request for this change if there's interest. The change would consist of checking for argv[1] in the main() functions of the generator sources listed above and calling chdir()/_chdir()/SetCurrentDirectory() on it (it's a bit more involved, but this issue is already long enough as is; the change itself is small) + making small changes to tests/cppgenerate-test-util.cmake.

For this change to be effective, the change would have to appear in a released version of libcppgenerate. It does not appear that a new version of libcppgenerate is planned to release soon, so a new release would have to be cut for this single change to take effect. I'll understand if you do not want to do this.

Summary

If you want to, I can add Meson to libcppgenerate. If you don't want to do that (which is probably wiser) but still want to make external Meson integration easier, tell me and I'll make a PR modifying problematic code in the testsuite. You'll have to merge and release that for it to take effect. If you do not want to either add a secondary build system to libcppgenerate or make a new release, tell me and I'll close this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions