[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Order of expansion of recipe lines

From: Brian Vandenberg
Subject: Re: Order of expansion of recipe lines
Date: Mon, 14 Mar 2016 10:44:34 -0600

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:


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):

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]