On Sat, May 10, 2014 at 12:07:22AM -0500, 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 This one should be in OS_CXXFLAGS already. > -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? I think I can vouch for this. The bikeshedding about how to name LIBRARY_DEFINES and/or how to define it in moz.build can be dealt with later. Once something is in moz.build, automatic rewrites are easy. Mike _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
