Re: MAKE_JOBS_ARG

Roland Illig <[email protected]> writes:

> Same here. My first impression was that a variable named XYZ_ARG would
> be a single argument that is passed to a shell command. Reading that the
> value can be set to "no" made me think of a special value that would be
> filtered out.
>
> The existing variables having the types "Yes" or "YesNo" differ wildly
> in their names. Some use the form USE_XYZ, so a better name might be
> USE_MAKE_JOBS. Or CUSTOM_MAKE_JOBS, with yes/no reversed.

This isn't really about whether MAKE_JOBS -- the number of threads that
should happen -- should be "used" or not.  That's what MAKE_JOBS_SAFE=no
means -- that while the user wants to use MAKE_JOBS=n, this package
won't do that.

The new variable is about whether a particular argument expressing that
value should be included in a call to the build step or not.

We could have

  MAKE_JOBS_METHOD

as a package-settable variable which defines the manner in which
MAKE_JOBS is expressed to the build.  Default would be "argj", which
adds -jN to the make stage, and could be "no" to indicate that the
package has code to pass it in some other way.  More precisely, "no"
means that the code in mk should not try to add any arguments about
MAKE_JOBS.

If we find common idioms, those could get a name, and the code to set it
that way be hoisted to mk/.  This could be useful for go, except that go
already centralizes the logic in a go mk file that is included by go
programs.  But as people keep inventing build systems they think are
better, while making interfaces gratuitously different, I'm sure we'll
need more!