[snoopybbt]

I don't know how many hours the author has spent/wasted on this topic (and how many people are now wasting their time coming up with other solutions that in the end do NOT fix the real problem), but...

Quite frankly, I find this whole "look i did a horrible hack and let's see who can make the best worst horrible hack" thing quite stupid and silly.

GNU Make is free software released under a free license, my opinion is that instead of doing that crazy thing, the author could have just written a patch for GNU Make in order to make it export a "JOBS" environment variable to all its child processes.

Oh but yes, "I felt this feature was missing so I added it" is way way way less cool than "geez the gnu make folks are insane lollerplex they have no way to know how many jobs they're running".

ALSO: http://www.catb.org/esr/faqs/hacker-howto.html#believe2

Here it is a patched version of GNU Make, providing a #J variable that holds the number of jobs as passed via -j/--jobs:

    http://santoro.tk/~manu/gnumake.png

As can be seen in the screenshot, it can be passed as environment variable to programs called by make

Source: https://github.com/esantoro/make

[LukeShu]

    > I don't know how many hours the author has spent/wasted
    > on this topic

The author, John Graham-Cumming, has been extremely active on the GNU Make mailing list, is the author of the "GNU Make Standard Library" of supplemental functions for Make, has written at least 2 books on GNU Make, and has developed commercial products that integrate with GNU Make (namely, "Electric Make").

That is to say: He is one of the world experts on GNU Make.

I'm confident that he did this more "for fun" than because he actually wanted to get the number of jobs.

[jgrahamc]

Yes. It was 'for fun'. Someone at CloudFlare asked me how to get the value of -j and I figured there must be some way :-)

[jordigh]

Do you know if this person hangs out in IRC? I asked this precise question 10 days ago in #emacs, and I was curious to see my precise question answered, almost the way I phrased it.

[jgrahamc]

Too funny. I think it's just random chance. Although he is an emacs user.

[DangerousPie]

Ignoring the fact that I doubt that the original post was serious:

Of course you can patch the software and in the long term that will of course be the best solution. But it can take a long time until that patch actually makes it into the main repo, and even longer until it will be in the default `make` on all major distributions. So if you want to use this feature right now then writing a patch is useless for you, unless you only ever use it on your own machine.

The big advantage of the workaround is that it actually works with current versions of make.

[snoopybbt]

Oh, I see your point.

Anyway, it was my small contribution to the discussion :-)

[jgrahamc]

Oh, boy. Take a chill pill man! Is no one allowed to do anything for fun any more?

It took me about 15 minutes to come up with the solution. I wrote it up for fun because it illustrates some of the functionality of GNU make that people might not be aware of (order-only prerequisites, $(eval)) and using $(call) in a recursive fashion.

I actually spent more time on the blog post.

[crististm]

I think it's because people resort to construct a parallel build machine with half-baked dependency resolution on top of make.

Asking for -j value inside the Makefile was a tell-tale sign of this sort.

[jordigh]

A parallel test, actually:

https://news.ycombinator.com/item?id=9283981

[snoopybbt]

Source from sample Makefile:

    default:	qualcosa.sh
    	JOBS=${#J} ./qualcosa.sh

Source for sample shell-script:

    #!/bin/bash
    
    echo "According to \$JOBS environment variable, the argument of -j/--jobs is $JOBS"