Open Bug 1501995 Opened 6 years ago Updated 2 years ago

Implement a meson to moz.build bridge

Categories

(Firefox Build System :: General, enhancement, P5)

enhancement

Tracking

(Not tracked)

People

(Reporter: achronop, Unassigned)

References

Details

Meson is implemented in Python 3. It would be a large amount of work but if the cost was worth it would be convenient for importing third party projects. Currently dav1d import is one.
See Also: → 1493400
We don't have the resources to implement this right now but would welcome patches!
Priority: -- → P5
One question to ask is whether it would be better to do it gyp style (do the work during configure) or gn style (do the work when updating to new upstreams)
(In reply to Mike Hommey [:glandium] from comment #2) > One question to ask is whether it would be better to do it gyp style (do the > work during configure) or gn style (do the work when updating to new > upstreams) I floated this idea after reading some things on the Meson homepage. Meson is implemented in Python, so it'd be feasible to vendor it and run it at configure time. We took the approach we did with gn because it's implemented in C++ and it doesn't run on all the platforms where people build Firefox. That being said, the cost/benefit on this might not be great if it's just for supporting dav1d.
We frequently just "bite the bullet" with vendored packages and manually port their build systems to moz.build files. Typically the cost of manually updating moz.build files with every vendored update is less than the cost of fully automating the conversion of the build system. Or we strike a middle ground and write a crude Python script that e.g. scans the directory for source files, annotates which files are special (e.g. platform specific), and spits out an autogenerated moz.build file, which we check into mozilla-central. Then when vendoring we look for changes to the upstream build system to make sure the assumptions in the script are still valid. For reference, dav1d's source can be consulted at https://code.videolan.org/videolan/dav1d.
I floated this idea as a possibility after looking at dav1d's build scripts. There's a non-trivial set of things happening there and I suspect we're going to wind up in the same boat we did with WebRTC where upstream is undergoing rapid development and we want to sync with upstream fairly frequently. The combination of those things makes keeping our build system in sync with upstream a nightmare.
Another option is to actually not parse the meson files, but run meson for each platform and parse the resulting ninja files (or compile_commands.json file). I think that would be easier than scanning for source files, in particular because dav1d compiles each source file multiple times, and with different options. A wilder choice is actually adding a moz.build backend to meson.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.