Yes, that would be a more flexible solution. This way N in -jN can come from all kinds of sources (e.g., from user's .profile).

One problem I have hit repeatedly in community-maintained free software projects is regressions in parallel building, both from the maintainers (who may not be explicitly specifying -jX) or from new contributors (who may not even know about -jX or whether the project supports parallel builds).

Experience has proven to me over and over again, that unless something is the default, it will constantly be broken. 

Now, most large-scale software projects with resources (time/money) likely have maintained autobuilders which very quickly catch regressions in parallel building.  But the smaller-scale projects won't, and even for the larger projects, it's useful to immediately catch regressions.

So what this patch does is add a .AUTOPARALLEL flag (in the spirit of .NOPARALLEL) which when seen automatically enables parallelism.  I chose a default of 8 jobs which feels reasonable; someone can later come by and add some heuristics based on system load, CPU cores, whatever.