On 5/11/2014 9:14 AM, Ehsan Akhgari wrote:
On 2014-05-10, 1:07 AM, Joshua Cranmer 🐧 wrote:
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?
Perhaps I missed this, but your post doesn't talk about why this
separation is useful. I don't understand why the existing command
lines in rules.mk are not useful...
The current setup hides a lot of the command line from
non-recursive-make systems. The most notable use case for this at the
moment are things like clang compilation databases or the Eclipse or VS
project backends, where we need several command-line flags to correctly
compile code. Hopefully that should be sufficient motivation for why
these ought to be visible at the moz.build level.
As to why I proposed the breakdown like this: I started with a pass that
would have remitted all the global flags to each backend.mk file by
directly porting config.mk logic to python, to which Mike Hommey
objected in part due to the redundancy of the emission (and also a
belief that this was configure's role, which I don't necessarily
disagree with).
Also, I think #3 and #4 above are already available separately in
moz.build (through SOURCES[foo.cpp].flags/pgo). How large is the #2
set? Can we just hardcode the binary specific flags somewhere? I
worry that adding more different types of flags would make moz.build
harder to use (for example, I don't think everyone understand why they
should use LOCAL_INCLUDES over CXXFLAGS = ['-I...'].
The only example that definitively exists right now is the
LIBXUL_LIBRARY-related -D set of flags. After looking at the sets of
flags in more detail, I think that NO_VISIBILITY_FLAGS and
DISABLE_STL_WRAPPING could be converted into #2-type flags, i.e., we
only the tighter visibility and STL-wrapping rules on a few libxul-like
libraries instead of having all our non-libxul libraries/programs flip
these flags.
As a side note, I envision that the LIBRARY_DEFINES would in the long
term be a set of flags defined on a Library() object, but having that
design in our build system ontology isn't a necessity for this proposal.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-builds mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-builds
