My apologies if this ends up being a double-post.

  I've gotten used to the fact that expansion occurs before recipe
invocation, but I'll lay out some of my thoughts on this.

  Currently, expansion occurs in the parent process before it fork()s.  One
of the things I was doing in the build looked something like this:

.RECIPEPREFIX := >

target : dependencies
> ${CC} $(patsubst -isystem${REPO_DIR}/%,-I%,$(patsubst
-I%,-isystem%,${INCLUDE_PATHS})) ...

There's other ways I could have accomplished the same thing that would have
removed the necessity, but for the sake of brevity lets not go into why.

As an experiment I replaced the $(patsubst) stuff with something that did
all the work in the shell and it improved parallel performance by a
noticeable amount.

This could be remedied by making it fork before recipe expansion so the
expansion happened in a sub-process.  On the plus side it eliminates
concerns of macros slowing down the parent make process but it breaks
backward compatibility for recipes using $(eval) that can induce dynamic
behavior during the recipe execution phase (eg, update variables during the
recipe expansion).

On the other hand:

I've written a plugin for our build.  I had toyed with adding a few simple
macros for getting the number of seconds, msec, usec, and nanosec since Jan
1 1970.  At first I thought I could use them for doing timing tests (eg,
how long it takes to compile each piece of code so we could find high
cardinality header inclusions making everything build slower):

.RECIPEPREFIX := >
target : deps
> $(eval asdf:=$(nanoseconds ))
> @do something
> @echo $(expr $(nanoseconds ) - ${asdf})

... but I quickly realized that would only measure the time it took to do
the expansion and would have no bearing on compilation time.

I ended up doing the above entirely in the shell.  I also added a macro for
measuring expansion time that's been quite valuable (prints a mean/standard
deviation to stderr after expanding N times).

In short: it wouldn't cause us problems to make a change like what you've
proposed, though I would like you to consider my suggestion for shifting
expansion to the sub-process as well.

-brian
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Reply via email to