On 22/12/2018 02:10, Brian Vandenberg wrote: > I usually instruct my co-workers to avoid making recipes along those > lines as I consider it to be a form of painting yourself into a corner, > though there are times where it's unavoidable. > > In the build I maintain it used to have something like this: > > blah.o : blah.xyz <http://blah.xyz> >> some command | sed 'some stuff' | some other command > blah.cc >> ${compiler and flags} blah.cc -o blah.o > > There were a few problems with it: > > * The 1st line of the recipe also produced a header as a side effect > (hidden dependency) > * This won't fail the build: /bin/true | /bin/false | /bin/true. That > can be changed if bash is the shell your build uses (.SHELL_FLAGS := > -euo pipefail -c) > * Even if one command in that pipeline fails the build it might not be > obvious what the failure was. > > I changed it to (extensions changed to protect the innocent): > > blah.x1 : blah.xyz <http://blah.xyz> >> some command > ${@} > > blah.x2 : blah.x1 >> sed 'some stuff' > ${@} > > blah.cc : blah.x2 >> some other command > ${@} > > blah.h : blah.cc >> no real recipe was provided, just adding this note for emphasis; this > last part is how I suggest you solve it
Perfect but this does not work in the situations I am interested in, that is where one single atomic command produces several files. Example: pdflatex produces several files and there are cases where you want to track some of them, e.g. document.pdf and document.aux. -- Renaud > > -brian > > On Wed, Dec 19, 2018 at 5:53 AM Renaud Pacalet <invalid.nore...@gnu.org > <mailto:invalid.nore...@gnu.org>> wrote: > > URL: > <https://savannah.gnu.org/bugs/?55243> > > Summary: Request for a way to indicate that the > same recipe > execution produces several targets > Project: make > Submitted by: pacalet > Submitted on: Wed 19 Dec 2018 12:53:09 PM UTC > Severity: 3 - Normal > Item Group: Enhancement > Status: None > Privacy: Public > Assigned to: None > Open/Closed: Open > Discussion Lock: Any > Component Version: 4.2.1 > Operating System: Any > Fixed Release: None > Triage Status: None > > _______________________________________________________ > > Details: > > This request for enhancement concerns cases where multiple targets are > produced by one single execution of a recipe. > > I frequently encounter situations where a single recipe execution > produces > several targets and I'd like make to know about all these targets. > > I know there is a side-effect of pattern rules with several targets > that leads > make to consider that all targets matched by one activation of the > rule are > produced by a single execution of the recipe. > > But exploiting this sometimes leads to clumsy Makefiles where > pattern rules > are used without any other reason than this side effect. Moreover, > building > the list of pattern targets is sometimes difficult. > > It would be much more convenient to have a new type of rule > dedicated to this > situation. For instance, a triple-colon rule: > > > a b c::: foo > touch a b c > > > Of course, there are several related questions, like, for instance: > > 0 the semantics of the $@ automatic variable (list of targets, first > target in > the list, other?), > 0 the existence or not of a corresponding (static) pattern rule, > 0 ... > > > > > _______________________________________________________ > > Reply to this item at: > > <https://savannah.gnu.org/bugs/?55243> > > _______________________________________________ > Message sent via Savannah > https://savannah.gnu.org/ > > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org <mailto:Bug-make@gnu.org> > https://lists.gnu.org/mailman/listinfo/bug-make > -- Renaud Pacalet Télécom ParisTech - LabSoC, c/o EURECOM Campus SophiaTech, 450 Route des Chappes, CS 50193 - 06904 Biot Sophia Antipolis cedex, FRANCE Tel : +33 (0) 4 9300 8402 Web : http://www.telecom-paristech.fr/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make