One of the goals of moz.build was to be able to start using alternative
build backends. Now, 18 months after we started working on it, how good
are we doing?
The build backend I'm most interested in isn't really a build backend,
but it's instructive nonetheless: clang compilation databases. Building
these databases requires an accurate accounting of both every source
file in the build and the complete command line used to build the file.
And you can't cheat by relying on make to do this for you--which is what
our existing non-make backends do. Recently, I attempted to make a
compilation database to see how good we are doing.
The experiment made one thing very clear: the emitter code is very, very
tied to Makefiles, and making the life of generating backend.mk easier
than the life of anyone trying to consume moz.build knowledge.
The worst offender is the list of source files: it is passed down as a
VariablePassthru in CSRCS, CPPSRCS, etc., and UNIFIED_CSRCS,
UNIFIED_CPPSRCS, etc. If you want to distinguish between source files in
the build directory and source files in the source directory, the only
way you can check is by peeking in GARBAGE. The logic for producing
unified builds happens in recursivemake.py, and I'm not sure how a clang
compilation database should handle that (considering it's a useful trick
for speeding compile times, and users clang compilation databases are
likely to want very fast world-rebuild times, though, it seems like it
should use it as much as possible).
A potential problem is knowledge not in moz.build land. Unconverted
Makefile.in variables are actually not a big problem here--there are at
most 10 Makefiles in the source tree (both comm-central and
mozilla-central!) that have a CSRCS or CPPSRCS variable not in a
moz.build file. It should be a relatively simple matter to ban the suite
of *SRCS variables in Makefile.in, and I plan to start working on
getting a ban on COMPILE_*FLAGS (conditional on there being some native
sourcefiles--we can't ban DEFINES in Makefile.in for what I hope are
obvious reasons) compiling over the next few months. No, the problem is
logic in config.mk... and variable definitions in configure.in.
Config.mk changes require duplicated logic (of roughly 2/3 of
config.mk!). Configure variables have a nasty tendency to produce values
with embedded Makefile strings like -include $(DEPTH)/mozilla-config.h.
I'd therefore like to see us make progress towards making non-make-based
backends viable in the infrastructure, in part by cleaning up the mess
that is our current backend logic and the communication between the
frontend and the backend in moz.build.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
