Re: bin/59962: make(1): grouped target rules for batch recipes

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59962; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/59962: make(1): grouped target rules for batch recipes
Date: Thu, 5 Feb 2026 07:11:10 -0000 (UTC)

 gnats-admin%NetBSD.org@localhost ("campbell+netbsd%mumble.net@localhost via gnats") writes:
 
 >	Tools like lex(1) and yacc(1) produce multiple output files
 >	foo.c and foo.h from a single input file foo.l/.y.  (Other
 >	examples abound, like TeX, Heimdal compile_et, and so on.)
 
 >	For _sequentiail_ make(1), this can be expressed with a rule
 >	having multiple targets:
 
 >foo.tab.c foo.tab.h: foo.y
 >	yacc -b foo foo.y
 
 >	However, this doesn't work for _parallel_ make(1): it may
 >	execute the same recipe twice for foo.tab.c and foo.tab.h
 >	independently.
 
 
 
 make behaves the same for sequential and parallel runs.
 
 A target list like:
 
 a b: sources
 	make_a
 	make_b
 
 
 is the same as
 
 a: sources
 	make_a
 	make_b
 
 b: sources
 	make_a
 	make_b
 
 
 When done sequentially, b is created as a side effect of
 building a, and building b is then skipped as the dependency
 for b is already fulfilled.
 
 When done in parallel, it's a race that is usually lost, and
 the actions for both targets are executed in parallel.
 
 A workaround is to specify an order like:
 
 .ORDER: a b
 a b: sources
 	make_a
 	make_b
 
 Which removes the race.
 
 
 It just looks like make would support a list of targets for
 a rule while in reality it just knows single files.