Rules with Multiple Outputs in GNU Make

I recently wrote an article for CM Crossroads exploring various strategies for handling rules that generate multiple output files in GNU make. If you’ve ever struggled with this problem, you should check out the article. I don’t want to spoil the exciting conclusion, but it turns out that the only way to really correctly capture this relationship in GNU make syntax is with pattern rules. That’s great if your input and output files share a common stem (eg, “parser” in parser.i, parser.c and parser.h), but if your files don’t adhere to that convention, you’re stuck with one of the alternatives, each of which have some strange caveats and limitations.

Here’s a question for you: if ElectricAccelerator had an extension that allowed you to explicitly mark a non-pattern rule as having multiple outputs, would you use it? For example:

What do you think? Comments encouraged.

Follow me

Eric Melski

Eric Melski was part of the team that founded Electric Cloud and is now Chief Architect. Before Electric Cloud, he was a Software Engineer at Scriptics, Inc. and Interwoven. He holds a BS in Computer Science from the University of Wisconsin. Eric also writes about software development at http://blog.melski.net/.
Follow me

Share this:

8 responses to “Rules with Multiple Outputs in GNU Make”

  1. Dave says:

    We’ve been avoiding the use of pragmas to preserve our ability to use other makes, although we have yet to use one.

    We would certainly consider it.

    • Eric Melski says:

      @Dave: Thanks for the feedback. The nice thing about pragmas in emake is that they are interpreted as comments by vanilla GNU make, so they are simply ignored — there’s no real risk of “lock in”. You could imagine using something like “#pragma multi” in conjunction with one of the solutions in the CM Crossroads article, so that with emake you get the fully correct behavior, and with gmake you get as close as possible within the constraints of the tool.

  2. Jean says:

    Why not proposing $(pragma ) for GNU make?

    • Eric Melski says:

      @Jean: I’m not really interested in improving the functionality of GNU make, because my livelihood is based on selling an alternative to it. I’m looking for new ways to make my offering more compelling in comparison to GNU make.

  3. Jean says:

    Oh, and Sun make has “target groups”

    target [+ target. . . ] :

    http://docs.sun.com/app/docs/doc/816-5165/make-1s

    • Eric Melski says:

      @Jean: That’s interesting. I didn’t know that Sun make had that feature. Unfortunately I don’t think that syntax would be a good choice for emake. With “#pragma multi”, the makefile would remain “parse compatible” with vanilla GNU make (because the pragma is just a special comment), but with target group syntax, the plus signs would cause trouble for vanilla GNU make.

  4. Jean says:

    I’ve know too little about emake so I didn’t even think that there are other “#pragma”ta. I don’t think you have to be paranoid about new syntactic features in GNU make: once they’re there, they ensure wide acceptance; emake should win by doing a better job with dependencies (thanks to electric fs), shouldn’t it?

  5. Jean says:

    Just noticed: PVM Gmake uses “+”
    http://pvmgmake.sourceforge.net/

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe

Subscribe via RSS
Click here to subscribe to the Electric Cloud Blog via RSS

Subscribe to Blog via Email
Enter your email address to subscribe to this blog and receive notifications of new posts by email.