785740 - Don't use $(@F) in COMPILE_* variables

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Gregory Szorc [:gps]]

I'm hoping glandium can address this as part of all the dependency refactoring going on...

In build splendid, I can't use COMPILE_CFLAGS and COMPILE_CXXFLAGS directly because COMPILE_CFLAGS may contain a $(@F) reference. This ultimately comes from configure.in starting at https://mxr.mozilla.org/mozilla-central/source/js/src/configure.in#4096

IMO, COMPILE_CFLAGS and COMPILE_CXXFLAGS should be target agnostic (unless they are evaluated in the context of a target for target-specific variables) and the compile rule itself should encode the output dependency file path (which is what $(@F) is used for).

Anyway, I have to resort to a gross hack which effectively emulates COMPILE_CFLAGS and COMPILE_CXXFLAGS. And, it isn't perfect. It would be much easier if I could evaluate these variables directly then append some DEPENDS_CFLAGS variable to the compiler command. e.g.

$(CPPOBJS): %.$(OBJ_SUFFIX): %.cpp
	$(REPORT_BUILD)
	@$(MAKE_DEPS_AUTO_CXX)
	$(ELOG) $(CCC) $(OUTOPTION)$@ -c $(COMPILE_CXXFLAGS) $(DEPENDS_CFLAGS) $(_VPATH_SRCS)
endif

I concede this bug is only useful to support simpler extraction of metadata from Makefiles. If it's marked WONTFIX, I'll understand.

Comment 1

[Gregory Szorc [:gps]]

FWIW, the alternative is for the evaluated per-Makefile value of COMPILE_CFLAGS to be workable in a non-recursive make file. This requires ensuring all paths are absolute, even -I arguments. Although, this could potentially be worked around in non-recursive make files by adding a "cd /path/to/src/file" before the compiler invocation. Even then, when you evaluate the COMPILE_CFLAGS variable using pymake, $(@F) is evaluated to an empty string. So, you really need some additional logic here, hence the initial request to eliminate $(@F).

Comment 2

[(not currently active) Ted Mielczarek]

I believe this is fixed nowadays, and the compiledb backend is proof of that.