From: janis_papanagnou+ng@hotmail.com   
      
   On 30.10.2025 21:21, Keith Thompson wrote:   
   > [...]   
   >   
   > The data structure that defines the '-j' option in the GNU make   
   > source is:   
   >   
   > static struct command_switch switches[] =   
   >   {   
   >     // ...   
   >     { 'j', positive_int, &arg_job_slots, 1, 1, 0, 0, &inf_jobs,   
   &default_job_slots,   
   >       "jobs", 0 },   
   >     //...   
   >   };   
   >   
   > Yes, it's odd that "-j" may or may not be followed by an argument.   
   > The way it works is that if the following argument exists and is   
   > (a string representing) a positive integer, it's taken as "-j N",   
   > otherwise it's taken as just "-j".   
      
   Incidentally in some recent (<2 years past) "C" program I needed   
   a lot of options to control the software. When I looked into the   
   man pages of getopt(3) in my GNU/Linux environment I noticed the   
   "optional optarg" capability of this 'getopt' version and I used   
   it deliberately for good reasons. - The opt-string specification   
   for this feature was done with a double-colon, as defined in   
     "s::d:f:r:g::u:a::m::kt::lqj::p::nci:o:"   
   for the program syntax   
     [-s[wxh]] [-d density] [-f pattern] [-r seed] [-g[ngen]] [-u rule]   
     [-a[gen]] [-m[rate]] [-k|-t[sec]|-l|-q] [-j[n]] [-p[symbol]|-n|-c]   
     [-i infile] [-o outfile]   
   The disambiguation with program arguments or other options was done   
   by writing _no space_ between the option letter and the optional   
   option-argument. So you could write, e.g., -j, or -j1, but not -j 1   
   (for those options that could have optional arguments).   
      
   I cannot tell, though, whether GNU make did use this getopt feature   
   similarly (or whether it had coded some ad hoc heuristic parsing).   
      
   >   
   > A make argument that's not an option is called a "target"; for   
   > example in "make -j 4 foo", "foo" is the target.  A target whose name   
   > is a positive integer is rare enough that the potential ambiguity   
   > is almost never an issue.  If it is, you can use the long form:   
   > "make --jobs" or "make --jobs=N".   
   >   
   > I think it would have been cleaner if the argument to "-j" had   
   > been mandatory, with an argument of "0", "-1", or "max" having   
   > some special meaning.  But changing it could break existing scripts   
   > that invoke "make -j" (though as I've written elsethread, "make -j"   
   > can cause problems).   
      
   I agree with having an explicit option argument would be clearer.   
      
   In my case above (and I don't know about the 'make' case discussed   
   in this thread) the -j had another semantics than -j0 (or such); I   
   needed both possibilities. So the option would have been (for me)   
   to add another (unrelated) option name from the very few remaining   
   letters and the choice would then have been arbitrary/non-mnemonic.   
   (For reasons I also didn't want to introduce long option names.)   
      
   >   
   > It would also have been nice if the "make -j $(nproc)" functionality   
   > had been built into make.   
      
   Yes. - This is actually how I'd have (with GNU 'getopt') designed it;   
   make (one instance), make -j (use max. available), make -j N (use N).   
      
   (Personally I dislike using the "C" programming pattern '-1' on the   
   user interface level to indicate "maximum" or some such.)   
      
   > The existing behavior is a bit messy, but it works, and I've never   
   > run into any actual problems with the way the options are parsed.   
      
   (I've never had any speed issues with make, so I've never used -j;   
   despite it comes "for free". - But I've also no 64 kernel CPUs or   
   MLOC-sized projects at home.)   
      
   Janis   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)