meson2hermetic: the world's premiere build system converter by gurchetansingh · Pull Request #15462 · mesonbuild/meson

gurchetansingh · 2026-01-12T22:09:24Z

This API converts meson.build into their corresponding hermetic representation (Android Blueprint, Bazel and maybe Buck2 in the future).

This is motivated by the need to integrate Mesa3D into AOSP and Fuchsia trees.

The question "how to build and update Mesa3D drivers for Android?" [1] in particular has led to several methods over the years, none of which used Android's native build system (Soong). This has been an obstacle to adoption of open-source drivers, which everyone knows are more secure, maintainable and faster than closed alternatives.

By integrating into Mesa3D's native build system (Meson), "meson convert" brings shocking and jaw-dropping clarity to the question.

Technically speaking, the tool works via a series of TOML files. Python 3.11 has tomlib in the standard library, and mconvert.py uses a conditional import strategy to prevent issues on older Python versions.

These TOML files specify:

the Meson project that is being converted
where to find the dependencies in a hermetic tree
which compilers that a hermetic tree supports

These TOML files are used to run the Meson interpreter multiple times. For example, the set of C/C++ flags may be different if the compiler targets x86_64 or ARM64. Data from each of of the meson interpreter runs is collated to reconstruct the full set of Soong/Bazel rules.

Although the initial implementation is focused with converting to a existing hermetic build system, this introduces infrastructure that could be useful if Meson itself takes a look at remote-executed, hermetic builds. For example, Meson can download prebuilts from NixPkgs.

[1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/13776

eli-schwartz · 2026-01-12T22:21:25Z

As relevant context, this tool was previously suggested by @gurchetansingh at #14134

/cc @dcbaker based on past discussions.

eli-schwartz · 2026-01-12T22:36:20Z

I haven't yet had an opportunity to take a close look at this. I see that it adds two new commands, one being the command to actually generate the hermetic buildsystem e.g. bazel, and another "check-toolchain" command that appears to be similar in spirit to the existing env2mfile command.

I'd like to hear a high-level explanation for what this tool does, to help better understand it. (And in particular, what are the challenges that make using machine files directly, not sufficient for your purposes? It looks like maybe the main differentiator is a lack of support for specifying the results of cc.has_* checks, but if that's the case then I'd like to implement that for machine files anyway...)

gurchetansingh · 2026-01-12T23:21:06Z

For reference, you can run the tool given the directions at:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39279

Right now, only mesa3d is supported.

I'd like to hear a high-level explanation for what this tool does, to help better understand it. (And in particular, what are the challenges that make using machine files directly, not sufficient for your purposes? It looks like maybe the main differentiator is a lack of support for specifying the results of cc.has_* checks, but if that's the case then I'd like to implement that for machine files anyway...)

One thing I like about .toml is the ability to use comments and have multiple tool-chains (I needed 6 tool-chains in the end to generate the right hermetic rules) in the same file, since IIUC is missing for the .ini files. Essentially, it seems to be the machine-files are just pared down versions of toml, which of course makes sense pre-Python 3.11. But with Python 3.11 on the horizon, using toml was very convenient and feature rich.

dcbaker · 2026-01-13T17:59:25Z

I will make a point to look at this in the near future.

As a bit of an aside: I'm stilling working on the ability to have meson definitions for LLVM, but I need to get more changes into Meson's dependency representation to be able to model that.

dcbaker · 2026-01-13T18:00:45Z

One thing I saw implementation wise from a quick glance, the new convert package has not been added to run_mypy.py, so we're not actually getting type checking. I'd really like to see that turned on for new code.

bonzini · 2026-01-14T15:40:30Z

@gurchetansingh please add stubs to docs/markdown/Commands.md so that CI passes.

To build the documentation you need to install hotdoc, then you can use

          cd docs
          ../meson.py setup _build
          ninja -C _build
          ninja -C _build test

gurchetansingh · 2026-01-15T18:29:37Z

As a bit of an aside: I'm stilling working on the ability to have meson definitions for LLVM, but I need to get more changes into Meson's dependency representation to be able to model that.

Nice. LLVM to hermetic is challenging as well like Mesa. Plus, I think many devs would enjoy an improvement over CMake.

convert package has not been added to run_mypy.py

Added: convert_interpreter.py is failing the CI though due to the current type checking config. That's understandable -- I added questionable code to pass run_mypy.py. BUT, when I remove questionable code, the script fails:

  File "meson/mesonbuild/convert/convertmain.py", line 26, in <module>
    from mesonbuild.convert.convert_interpreter import ConvertInterpreter
  File "meson/mesonbuild/convert/convert_interpreter.py", line 18, in <module>
    from mesonbuild.interpreter import kwargs
  File "meson/mesonbuild/interpreter/kwargs.py", line 15, in <module>
    from ..dependencies.base import Dependency, DependencyMethods, IncludeType
ImportError: cannot import name 'IncludeType' from 'mesonbuild.dependencies.base' (meson/mesonbuild/dependencies/bas

But should IncludeType only be required with T.TYPE_CHECKING? Could be related to recent refactors.

dcbaker · 2026-01-15T19:11:12Z

@gurchetansingh: interpreter/kwargs.py should only be imported inside a T.TYPE_CHECKING block. Or, at least it currently has that assumption.

dcbaker

I've started looking purely at the implementation details of this, but I haven't looked too much at the design yet. It's a lot of code and this is giving me a chance to try to get familiar with it.

I haven't looked at the soong implementation yet, and I'm about half way through the instance code of the third patch. I still need to get to reference/ and to top level convert/ file and mconvert.py

One thing I'd really like to have is some more comments, particularly docstrings to help explain how all of the code fits together, and what each thing is for, there's a lot of code here and it would really help me to review it (and for us to maintain it).

dcbaker · 2026-01-15T19:18:41Z

+    parser.add_argument("-o", "--output", default=None, help="Output file name.")
+
+
+def run(options: argparse.Namespace) -> int:


We do have some uses of Protocol in these front end functions to help with accurate typing vs using Namespace, I'm not sure how practical that is in this case.

left as is since most other commands use namespace

dcbaker · 2026-01-15T19:23:18Z

+class AbstractCompiler(Compiler):
+    def __init__(self, conf: T.Dict[T.Any, T.Any], *args: T.Any, **kwargs: T.Any):
+        self.conf = conf
+        super().__init__(*args, **kwargs)


I'm not crazy about the heavy use of Any here, but I need to think more about whether there's another good option.

Indeed, why can't the list of arguments just be copied from Compiler?

dcbaker · 2026-01-15T19:26:28Z

+    def find_library(
+        self,
+        libname: str,
+        extra_dirs: T.List[str],
+        libtype: LibType = LibType.PREFER_SHARED,
+        lib_prefix_warning: bool = True,
+        ignore_system_dirs: bool = False,
+    ) -> T.Optional[T.List[str]]:


Please do not use the black style especially this thing it does, it's a really weird style for python and we don't use it elsewhere, the ) -> T.Optional[...]: should not be dedented tot he same level as def

one of:

def find_library(self, libname: str, ...): ... def find_library(self, libname: str, ...): ... def find_library( self, libname: str, ...): ...

Would be consistent with our style elsewhere.

I added a simple .style.yapf based on pep8 . It dedents to the same level as the function definition much less than ruff (the prior tool I used). It does in a few select cases, but I think those cases are reasonable. LMK otherwise, and I can skip the linters and hand-code to match the style you want.

gurchetansingh · 2026-01-16T20:56:02Z

One thing I'd really like to have is some more comments, particularly docstrings to help explain how all of the code fits together, and what each thing is for, there's a lot of code here and it would really help me to review it (and for us to maintain it).

Added more docstring comment. I would recommend reviewers start in convertmain.py.

gurchetansingh · 2026-03-16T16:23:57Z

Changelog since last update

1. meson-to-Bazel for Fuchsia

A Bazel backend functional enough to compile gfxstream_vk for Fuchsia.

If you have:

Bazel installed (https://bazel.build/install)
and the Mesa MR (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40443)
this MR

here is the command to test:

>> ~/mesa3d $ python3 ~/meson/meson.py convert fuchsia mesa3d
>> ~/mesa3d $ bazel build //src/gfxstream/guest/vulkan:vulkan_gfxstream --platforms=//bazel/platforms:fuchsia_x86_64_platform --host_platform=@platforms//host

2. Enhanced meson check-toolchain

Now supports downloading from a [compiler_binaries.wrap] section with standard parameters (source_url, source_hash, source_filename).

3. Unit tests for CI/CD

To make sure the tool works as expected. Looks like the unittests are failing on platforms without Python 3.11, and that will be addressed in a future update.

4. formatter issues fixed

This style uses ruff as the formatter, but it's turned off for parts Meson developers especially hate (like the function defintions). One thing that would be nice if Meson had an officially supported formatter or style file (regardless of which one it is).

meson2hermetic: a guide for reviewers

At its core, meson2hermetic is a two-step build system transpiler.

1. meson check-toolchain

This tool probes a toolchain (like the Android NDK or Fuchsia SDK) to see which headers, functions, and flags are supported, saving the results for the conversion process.

    DOWNLOADS               EXECUTION                OUTPUT
 +--------------+    +-----------------------+    +----------------+
 |  Android NDK |    |  Meson Introspection  |    |                |
 |      OR      |--->|  & Compiler Probing   |--->| toolchain.toml |
 |  Fuchsia SDK |    | (check_header, etc.)  |    |                |
 +--------------+    +-----------------------+    +----------------+
                                ^
                                |
                         +--------------+
                         |  Cross File  |
                         +--------------+

2. meson convert

This tool takes a standard Meson project and translates it into a different build system (Soong or Bazel) using the metadata gathered by the toolchain checker.

     INPUTS                   PROCESSING                    OUTPUTS
 +-------------+      +----------------------+      +----------------+
 | meson.build |      |   Custom Abstract    |      |   Android.bp   |
 +-------------+      |   Meson Interpreter  |      |    (Soong)     |
        +             +----------------------+      +----------------+
 +-------------+                 |                          OR
 | project.toml|                 v                  +----------------+
 +-------------+      +----------------------+      |   BUILD.bazel  |
        +             |   Build-Agnostic     |      |     (Bazel)    |
 +-------------+      |   State Tracker      |      +----------------+
 |toolchain.toml|     +----------------------+              ^
 +-------------+                 |                          |
                                 v                  +----------------+
                      +----------------------+      |    Emitter     |
                      | Dependency Resolving |----->|    Backend     |
                      +----------------------+      +----------------+

FAQ

1. Does the tool handle the entire Meson API?

Not yet. build.Executable is one notable area where I haven't had a way to test yet (but it's on the radar). configuration-data too

2. How stable are the new APIs?

The tool is useful for developers integrating FOSS projects into gigantic monorepos. This is a niche audience. So the tool's API will likely be considered "experimental" and subject to change for a while (six months to 1 year).

Specifically, this flow uses TOML files to handle multiple compilers/sysroots, but I'm unsure if the approach is exactly right (though I don't think Bazel handles that well either). If a better representation emerges, this tool will likely migrate.

3. Is this only useful for Mesa3D?

Some people also need hermetic QEMU builds, and someone was playing around with DPDK + Bazel (magma-gpu/mesonbuild#2). It's a niche audience, but not limited to Mesa3D alone.

4. Why not use AI to transpile?

The project was conceived before generative AI tools were widely available. But for the same reasons clang/gcc are better than AI-to-bytecode conversion, a dedicated tool offers better utility. Specifically:

AI is not deterministic. Depending on model/prompt/infra, different results.
It probably won't work without anything that constrains the search, like the TOML files do in this case. Creating the harness could be just as complex as this tool.
Where will the AI harness be run?
For a first pass, AI could take days of trial and error to achieve the initial conversion. Incremental updates with AI would be easier though.
AI token prices are currently heavily subsidized, and prices may rise in the future.

dcbaker · 2026-03-23T16:00:43Z

@gurchetansingh: I need to apologize for being rather slow on reviewing this. I'll be offline for a bit, but this is on the top of my list to get back to when I return to work.

gurchetansingh · 2026-04-03T23:08:52Z

Newest update

We are using the tool right now for external/mesa3d and it should be publicly visible in the android17-qpr2 update. The latest update is mostly focused on quality: we managed to shave the auto-generated code count from 12.6 kLOC (for only two drivers) to 9.8 kLOC via smarter handling of filegroups/include_directories.

Shower thoughts

I was reading:

https://blogsystem5.substack.com/p/bazel-next-generation

My personal belief is that we need two build systems that speak the same protocol (Starlark and Bazel’s build API) so that users can interchangeably choose whichever one works best for their use case:

On the one hand, we need a massively scalable build system that does all of the work in the cloud. This is to support building monorepos, to support super-efficient CI runs, and to support “headless” builds like those offered by hosted VSCode instances. Bonanza seems to have the right ideas and the right people behind it to fulfill this niche.

On the other hand, we need a tiny build system that does all of the work locally and that can be used by the myriad of open-source projects that the industry relies on. This system has to be written in Rust (oops, I said it) with minimal dependencies and be kept lean and fast so that IDEs can communicate with it quickly. This is a niche that is not fulfilled by anyone right now and that my mind keeps coming to; it’d be fun to create this project given my last failed attempt.

In many ways, meson2hermetic makes the same observations. meson is the preferred build system of local Linux-based open-source projects. However, integrating open-source projects is increasingly done in the hermetic Bazel style.

It's also good to think about Meson eventually handling monorepo style projects one day -- will it continue to stay in its niche or have a unique take on the hermeticization issue? 🤔

dcbaker · 2026-04-06T17:26:38Z

It's also good to think about Meson eventually handling monorepo style projects one day -- will it continue to stay in its niche or have a unique take on the hermeticization issue? 🤔

I have done some thinking about this, you may be interested in #14147, on that issue.

gurchetansingh · 2026-04-27T16:07:37Z

I have done some thinking about this, you may be interested in #14147, on that issue.

That issue and the related issues were useful. As a result, I changed the API from meson check-toolchain [..] to meson check-platforms.

A platform is in line with the Bazel concept: a collection of sysroots, OS, architecture and toolchains which define a machine. For example, android_arm64 can be considered a platform. It's the same information as a MachineFile, but TOML enables a more compact representation of multiple platforms in a single file. Long-term, one may do something like:

meta-meson compile //llvm/ -Dplatforms=android_arm64

where Meson itself would understand what that means.

dcbaker

I made it about half way through a first read through of this in a while. I'll have more comments and it's a large enough PR that I'll probably clone it locally and have a more hands on look. I'll try to get through the rest of the first re-read tomorrow.

gurchetansingh · 2026-04-29T01:29:55Z

I'll wait for the complete review before uploading a new version.

Though, a question about the formatting: is the Meson style to ignore all hanging parenthesis, or just ones in specific places (function definitions, conditionals/with statements)?

For example, is a statement like

                t.wraps[clang_wrap_name] = WrapInfo(
                    name=clang_wrap_name,
                    source_url=clang_url,
                    source_filename="fuchsia-clang-linux-amd64.zip",
                    source_hash=clang_hash,
                )

allowed? Or should it be:

                t.wraps[clang_wrap_name] = WrapInfo(
                    name=clang_wrap_name,
                    source_url=clang_url,
                    source_filename="fuchsia-clang-linux-amd64.zip",
                    source_hash=clang_hash)

Though, I'll note all formatters (ruff, black, yapf) all use hanging parenthesis somewhere, although in different places.

gurchetansingh · 2026-06-26T15:02:30Z

Is it okay for you to start with convert and extract the current code for check-platforms to a new draft PR?

Sounds good.

gurchetansingh · 2026-07-14T00:57:09Z

I've removed check-platforms from this PR and put it into a draft PR:

#16006

Most of the project-specific knowledge is gone and will be put into the revelant project. For example, here is a PR to Mesa for the TOML files:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42932

There is a small amount of project specific knowledge in mesonbuild/hermetic/hermetic_projects.py. This is for user convenience so one doesn't have to type long paths for common projects.

The most significant change is the introduction of mesonbuild/hermetic. This is for common code shared by both convert and check-platforms (dependency, compiler and interpreter management). Otherwise, very similar to prior versions, and should be sufficient to unblock the QEMU work.

These are TOML files for meson2hermetic: mesonbuild/meson#15462 This makes the Android build of rutabaga_gfx a bit more maintainable and cleaner.

gurchetansingh · 2026-07-21T19:47:23Z

The latest version added support for rust.bindgen(..) and build.Executable for Rust binaries to enable Soong transpilation for rutabaga_gfx (magma-gpu/rutabaga_gfx#64).

That should help allay concerns that the tool is Mesa3D specific. I was thinking about doing glslang too, but it doesn't have a native meson.build support yet. It would be better to wait until this MR lands to provide the motivating scenario.

gurchetansingh · 2026-07-29T17:36:24Z

[No major changes; just a rebase awaiting further review]

gurchetansingh · 2026-08-06T18:11:40Z

CI failures/hang look to Github Actions being down today: https://www.githubstatus.com/. Everything works locally.

@bonzini @dcbaker ping again for re-review. There are four downstream meson-to-{X} solutions out there (example 1, example 2, example 3). Someone just pinged me about Mesa-to-GN for Chrome (yes, they have their own hermetic builds system too).

Taken against this err .. um .. less than optimal status quo, this is a definite win!

jpakkane · 2026-08-20T14:07:27Z

Some of the test cases are put in test cases/unit/hermetic. That does not follow the naming scheme, which is test cases/(type)/number - name. Some tooling depends on this, most importantly tools/dircondenser.py.

I agree with bonzini's comment from above: project-specific knowledge (e.g. Mesa-specific) should absolutely not be in Meson. It is very likely that they need to be changed faster than we can do Meson releases. People might also need to do conversions on multiple different Meson versions on different machines, which means that they want to use the exact same conversion parameters.

where to find the dependencies in a hermetic tree

This feels a bit like a feature that would be useful as a standalone thing. For example if people want to do Windows development and use prebuilt libs without using pkg-config or something similar. Then you could have a file that says "dependency named X exists and to use it you add these compiler flags and these linker flags".

This will allow overrides (used by convert) of the Rust module to leverage these.

Fix some easy-to-see type checking errors.

This distills what I've learned about the Meson formatting rules into a [tool.ruff]. This is only applicable to the new meson2hermetic code right now, and others who want to use some formatter in their contributions has well. This of course is not meant to be adopted project-wide. There is a disclaimer about trusting the tool and the "Black" style without auditing it's output.

The testname is useful as a key to precomputed compiler checks dictionary: [platform.cpp.links.fails] "GNU qsort_r" = true "BSD qsort_r" = true

This API converts meson.build into their corresponding hermetic representation (Android Blueprint, Bazel and maybe Buck2 in the future). This is motivated by the need to integrate Mesa3D into AOSP and Fuchsia trees. The question "how to build and update Mesa3D drivers for Android?" [1] in particular has led to several methods over the years, none of which used Android's native build system (Soong). This has been an obstacle to adoption of open-source drivers, which everyone knows are more secure, maintainable and faster than closed alternatives. By integrating into Mesa3D's native build system (Meson), "meson convert" brings shocking and jaw-dropping clarity to the question. Technically speaking, the tool works by via series of TOML files. Python 3.11 has tomlib in the standard library, and mconvert.py uses a conditional import strategy to prevent issues on older Python versions. These TOML files specify: * the Meson project that is being converted * where to find the dependencies in a hermetic tree * which compilers that a hermetic tree supports These TOML files are used to run the Meson interpreter multiple times. For example, the set of C/C++ flags may be different if the compiler targets x86_64 or ARM64. Data from each of meson intrepreter runs is collated to reconstruct the full set of Soong/Bazel rules. Although the initial implementation is focused with converting to a existing hermetic build system, this introduces infrastructure that could be useful if Meson itself takes a look at remote-executed, hermetic builds. For example, Meson can download prebuilts from NixPkgs or grow the ability to handle other projects. Used in Android17+ mesa3d now [2]. [1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/13776 [2] https://android.googlesource.com/platform/external/mesa3d/+/refs/heads/android17-release/Android.bp Co-developed-by: Craig Stout <cstout@google.com> Co-developed-by: Brandon Nguyen <bpnguyen@google.com>

For convert: - add to mesonmain.py - add Commands.md

This adds CI/CD + unittest for 'meson convert'. Idea is simple: - have meson.build files - have "golden" Soong/Bazel files - run meson convert - compare with the goldens. Test command: - python3 run_unittests.py ConvertTests Regenerate goldens when needed: >> cd ~/meson/test cases/unit/138 hermetic basic >> ~/meson/test cases/unit/138 hermetic basic $ python3 ~/meson/meson.py convert test basic_soong >> ~/meson/test cases/unit/138 hermetic basic $ python3 ~/meson/meson.py convert test basic_bazel

gurchetansingh · 2026-08-20T17:29:15Z

That does not follow the naming scheme, which is test cases/(type)/number - name. Some tooling depends on this, most importantly tools/dircondenser.py.

Ack, fixed in the latest version. The test data is now in test cases/unit/138 hermetic basic (there was nothing between 137 and 139 in ToT).

I agree with bonzini's comment from above:

Agreed and that was fixed in the July revision. The only project specific logic is in 50-line hermetic_projects.py, which is a small bit of convenience for power users (and in line with other existing project-specific Meson code, like GNOME/Wayland modules).

This feels a bit like a feature that would be useful as a standalone thing. For example if people want to do Windows development and use prebuilt libs without using pkg-config or something similar.

Yes, I think it should be fairly simple if someone wants to reuse the TOML structure to define a HermeticDependenciesToml object and WindowsDependenciesToml (with a common base class). The semantics would be slightly different: on hermetic systems, the "target_name" is enough to propagate linker + compiler flags.

gurchetansingh requested a review from jpakkane as a code owner January 12, 2026 22:09

gurchetansingh force-pushed the meson2hermetic branch from c9ebe87 to d3dff63 Compare January 12, 2026 22:13

eli-schwartz added enhancement OS:android labels Jan 12, 2026

gurchetansingh force-pushed the meson2hermetic branch from d3dff63 to f8081d8 Compare January 15, 2026 17:49

dcbaker requested changes Jan 15, 2026

View reviewed changes

gurchetansingh force-pushed the meson2hermetic branch from f8081d8 to a2f97c3 Compare January 16, 2026 20:11

gurchetansingh force-pushed the meson2hermetic branch 2 times, most recently from ac3a82c to 65b375a Compare March 16, 2026 16:11

gurchetansingh force-pushed the meson2hermetic branch from 65b375a to b1c12f5 Compare March 16, 2026 17:54

gurchetansingh force-pushed the meson2hermetic branch from b1c12f5 to 8904ffe Compare April 3, 2026 22:50

gurchetansingh force-pushed the meson2hermetic branch from 8904ffe to 3f1ca29 Compare April 3, 2026 23:59

gurchetansingh force-pushed the meson2hermetic branch from 3f1ca29 to 7578d53 Compare April 27, 2026 15:11

gurchetansingh force-pushed the meson2hermetic branch from 7578d53 to 424140d Compare April 27, 2026 22:56

dcbaker requested changes Apr 28, 2026

View reviewed changes

gurchetansingh force-pushed the meson2hermetic branch 2 times, most recently from 240cbff to 6d6bad4 Compare July 14, 2026 00:53

gurchetansingh force-pushed the meson2hermetic branch 4 times, most recently from af1a6e7 to 9217da5 Compare July 15, 2026 01:30

gurchetansingh added a commit to magma-gpu/rutabaga_gfx that referenced this pull request Jul 21, 2026

rutabaga_gfx: add build toml files

a1a5b5a

These are TOML files for meson2hermetic: mesonbuild/meson#15462 This makes the Android build of rutabaga_gfx a bit more maintainable and cleaner.

gurchetansingh force-pushed the meson2hermetic branch 4 times, most recently from 670f48b to 2345b42 Compare July 21, 2026 19:29

gurchetansingh force-pushed the meson2hermetic branch from 2345b42 to 58acafc Compare July 29, 2026 17:29

gurchetansingh force-pushed the meson2hermetic branch 2 times, most recently from 2c64b00 to 6b92c7c Compare August 6, 2026 17:51

gurchetansingh force-pushed the meson2hermetic branch from 6b92c7c to d395b9a Compare August 7, 2026 14:57

gurchetansingh added 7 commits August 20, 2026 08:03

mesonbuild: rust: expose BINDGEN_KWS + CBINDGEN_KWS externally

61e3cd2

This will allow overrides (used by convert) of the Rust module to leverage these.

mesonbuild: modules: rust: fix some type checking errors

ea3c607

Fix some easy-to-see type checking errors.

mesonbuild: compilers: forward testname to compiler implementations

4894dc9

The testname is useful as a key to precomputed compiler checks dictionary: [platform.cpp.links.fails] "GNU qsort_r" = true "BSD qsort_r" = true

meson: core changes to enable convert API

ebab0bb

For convert: - add to mesonmain.py - add Commands.md

gurchetansingh force-pushed the meson2hermetic branch from d395b9a to 65ff55f Compare August 20, 2026 17:01

		parser.add_argument("-o", "--output", default=None, help="Output file name.")


		def run(options: argparse.Namespace) -> int:

Uh oh!

Uh oh!

Conversation

gurchetansingh commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eli-schwartz commented Jan 12, 2026

Uh oh!

eli-schwartz commented Jan 12, 2026

Uh oh!

gurchetansingh commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dcbaker commented Jan 13, 2026

Uh oh!

dcbaker commented Jan 13, 2026

Uh oh!

bonzini commented Jan 14, 2026

Uh oh!

gurchetansingh commented Jan 15, 2026

Uh oh!

dcbaker commented Jan 15, 2026

Uh oh!

dcbaker left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dcbaker Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

gurchetansingh Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dcbaker Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

bonzini Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

dcbaker Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

gurchetansingh Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gurchetansingh commented Jan 16, 2026

Uh oh!

gurchetansingh commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog since last update

1. meson-to-Bazel for Fuchsia

2. Enhanced meson check-toolchain

3. Unit tests for CI/CD

4. formatter issues fixed

meson2hermetic: a guide for reviewers

1. meson check-toolchain

2. meson convert

FAQ

1. Does the tool handle the entire Meson API?

2. How stable are the new APIs?

3. Is this only useful for Mesa3D?

4. Why not use AI to transpile?

Uh oh!

dcbaker commented Mar 23, 2026

Uh oh!

gurchetansingh commented Apr 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Newest update

Shower thoughts

Uh oh!

dcbaker commented Apr 6, 2026

Uh oh!

gurchetansingh commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

gurchetansingh commented Jan 12, 2026 •

edited

Loading

gurchetansingh commented Jan 12, 2026 •

edited

Loading

gurchetansingh commented Mar 16, 2026 •

edited

Loading

gurchetansingh commented Apr 3, 2026 •

edited

Loading

gurchetansingh commented Apr 27, 2026 •

edited

Loading

gurchetansingh commented Apr 29, 2026 •

edited

Loading