One of the most useful things to export to moz.build backends is the
ability to represent compile commands faithfully--for example, for
things like IDE integration or clang compilation databases. Our
moz.build migrations have moved most of the obvious stuff (DEFINES,
LOCAL_INCLUDES), but there are still some critical logic rules missing:
-DIMPL_LIBXUL, -DMOZILLA_INTERNAL_API
-include $(DEPTH)/mozilla-config.h
-std=gnu++0x
-I/usr/include/gtk-2.0 (i.e., TK_CFLAGS where directories need them).
The current command line rules in rules.mk looks like this:
$(CC) $(OUTOPTION)$@ -c $(COMPILE_CFLAGS) $($(notdir $<)_FLAGS)
$(TARGET_LOCAL_INCLUDES) $(_VPATH_SRCS)
where $(COMPILE_CFLAGS) is a very nasty command-line option requiring
about 1/3 of config.mk to construct.
In theory, we can break down the basic structure of COMPILE_CFLAGS and
friends into four categories of flags:
1. Global flags (e.g., -DDEBUG, -std=gnu++0x).
2. Binary-specific flags (e.g., -DIMPL_LIBXUL). (i.e., these ought to
propagate according to FINAL_LIBRARY).
3. File-specific flags
4. PGO mode-dependent flags. In practice, these flags oughtn't be
necessary for most integration project tools
[The role of NO_VISIBILITY_FLAGS, DISABLE_STL_WRAPPING, and
FAIL_ON_WARNINGS is kind of vague on this point. In theory,
NO_VISIBILITY_FLAGS and DISABLE_STL_WRAPPING should apply equally across
all levels of FINAL_LIBRARY, but I'm willing to bet that they don't
right now. I'm treating FAIL_ON_WARNINGS as effectively a file-specific
flag for this categorization purpose.]
In theory, we ought to be able to cleanly separate these rules so we
could define a compile rule like this:
$(CC) $(OUTOPTION)$@ -c $(GLOBAL_CFLAGS) $(BINARY_CFLAGS) $(PGO_CFLAGS)
$($(notdir $<)_FLAGS) $(_VPATH_SRCS)
[This is less true for linking-level flags, but the most important use
cases are concerned with the compile lines, not the link lines, so I'm
willing to punt on that for now.]
With this in mind, I'd like to propose working on this issue by doing
the following steps:
1. Start combining the global flags into a single GLOBAL_CFLAGS rule,
and make the logic for emitting this happen at configure-time, not in
config.mk. I kind of prefer doing this in moz.build somehow since python
is a far easier language to do logic in than Makefile or m4-augmented
shell-script, but as long as this knowledge is easily communicable to
moz.build (e.g., via CONFIG), that should satisfy most use cases.
2. Introduce a LIBRARY_DEFINES rule that acts like DEFINES but adds its
defines to all libraries within the same FINAL_LIBRARY set. This model
is meant to extend to other options like potentially EXTRA_DSO_LDOPT or
LIBS rules, but I'm not actively targetting linking right now.
Thoughts/comments/questions/concerns/responses/flames?
--
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
