Question

I’m working on re-writing an old build that was originally “designed” (or not, as the case may be) to be recursive. To preface, there will come a day when we’ll move to something more modern, expressive, and powerful (eg, scons); however, that day is not now.

As part of this effort I’m in the process of consolidating what should be generic variables/macros & targets/recipes into a few concise rulefiles that’ll be included as part of the primary build. Each sub-section of the build will use a small makefile that adds targets & dependencies with little in the way of variables being added in these sub-makefiles. The top level makefile will then include all the makefiles, allowing everything to contribute to the dependency tree.

I must admit I’m not at all confident that people will use good judgement in modifying makefiles. As an example of what I’m worried about:

CFLAGS = initial cflags
all: A.so
%.so %.o:
  @echo "${@}: ${CFLAGS} : ${filter 5.o,${^}} ${filter %.c,${^}"

%.c :
  true

%.o : %.c
A.so : B.so a1.o a2.o a3.o
B.so : b1.o b2.o b3.o
A.so : CFLAGS += flags specific to building A.so

Provided I didn’t screw up copying that example, the situation is thus: A.so would link to B.so, and A.so‘s objects need special flags to be built; however, B.so and B‘s objects will inherit the changes to CFLAGS.

I would prefer to have a single target for building most if not all object files, even to the extent of modifying CFLAGS specifically for those those objects that need slightly different flags, in order to promote re-use of more generic targets (makes debugging easier if there’s only one target/recipe to worry about).

After I finish re-architecting this build, I’m not at all confident someone won’t do something stupid like this; worse, it’s likely to pass peer review if I’m not around to review it.

I’ve been kicking around the idea of doing something like this:

% : CFLAGS = initial cflags

… which would prevent dependency poisoning unless someone then updates it with:

% : CFLAGS += some naive attempt at altering CFLAGS for a specific purpose

However, if there’s, just 1000 targets (an extremely conservative estimate), and approximately 1k in memory allocated to variables, then we’re up around 1mb of overhead which could significantly impact the time it takes to lookup the CFLAGS value when working through recipes (depending on gmake’s architecture of course).

In short, I suppose my question is: what’s a sane/good way to prevent dependency poisoning in a makefile? Is there a better strategy than what I’ve outlined?

---

edit

If anyone out there attempts to go down the path of scoping variables as described above, I ran into a nuance that wasn’t entirely obvious at first.

% : INCLUDES :=
# ...
SOMEVAR := /some/path
% : INCLUDES += -I${SOMEVAR}
...
SOMEVAR :=

When a variable is created using :=, everything to the right of := should be evaluated immediately, whereas if it just used = it would delay evaluation until the target recipe evaluates INCLUDES.

However, SOMEVAR evaluates to nothing when a target recipe is evaluated. If you change the definition to:

% : INCLUDES := whatever
# ...
SOMEVAR := /some/path
% : INCLUDES := ${INCLUDES} -I${SOMEVAR}
...
SOMEVAR :=

… then it forces SOMEVAR to be evaluated immediately instead of delaying evaluation, but INCLUDES doesn’t evaluate to its previously scoped definition, rather to the global definition.

$(flavor ...) says INCLUDES is simple, and $(origin ...) returns file; this occurs whether you use := or +=.

In short, if you use += on scoped variables, it’ll only use the definition of the variable scoped to that target; it doesn’t look at globals. If you use :=, it only uses globals.

Answer 1

If you abstain from unusual characters in your filenames, you can select target-specific variables with variable name substitution:

A.so_CFLAGS = flags specific to building A.so
%.so %.o:
    @echo "${@}: ${CFLAGS} ${$@_CFLAGS} : ${filter %.o,${^}} ${filter %.c,${^}}"

Which obviously doesn’t propagate the name of the currently built archive to the objects built for that library, but I don’t know if this is desired.

This approach has some obvious deficiencies, naturally, like the inability to actually override CFLAGS. However, considering that automake has the same problem to solve and resorts to stupid text substitution, I think a lot of people already failed to find a nice solution here.

As a side-note, you might consider using automake instead of re-engineering it.