bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #55243] Request for a way to indicate that the same recipe exec


From: Brian Vandenberg
Subject: Re: [bug #55243] Request for a way to indicate that the same recipe execution produces several targets
Date: Fri, 28 Dec 2018 18:25:59 -0700

> 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

I may be mistaken, but this sounds like a problem I tried tackling: force PDF's to re-build if any of its dependencies changed.  I started with pdftex's "-recorder" flag, but it doesn't allow you to control output filename / directory and there were other problems that made it completely un-suited to generating a dependency list.  After looking at all the docs, what others on the internet tried, etc, I was ready to throw in the towel.

The following ugly hack came about as I was thinking about how nice it'd be if I had something "magic" (eg, tup's use of fuse) to 'discover' what files were accessed; this is roughly what I threw together:

$ cat blah.sh
#!/bin/bash
set -euo pipefail
strace -y -f -o blah.dep.tmp pdflatex -halt-on-error -interaction=batchmode "address@hidden"
perl -ni -e 'while( m{<([^>]+)>}g ) { my $tmp = $1; $tmp =~ m{'^$(pwd)'} && print "$tmp\n"}' blah.dep.tmp
echo "address@hidden : $(sort -u blah.dep.tmp)" > blah.dep

$ cat makefile
-include $(shell find docs -name '*.dep')
# note lack of dependencies listed; they come from the .dep files
%.pdf :
> blah.sh address@hidden

Explanation:
* First time the build runs .dep files don't exist and it'll just assume everything is ok; subsequent builds will have all necessary dependencies
* The "-y" flag in strace causes it to emit paths or descriptive text (eg, socket:12344321) in <>s for file descriptor arguments to functions:
fstat(3</path/to/some/file>, {st_mode=S_IFREG|0644, st_size=170187, ...}) = 0
* The paths within <> are always fully qualified; the perl one-liner extracts each path and if it is a descendent of $(pwd) it gets printed; obviously the paths need to be filtered further to distinguish between output -vs- input, etc; the above is just a rough sketch

Problems:
* It's stupid; clever, but stupid
* Platforms without strace would require a different solution
* The "-y" flag is a relatively recent addition to strace; without it, extracting valid paths is more error prone.

dtrace (solaris/bsd) and system tap (linux) scripts are also an option; in fact if I weren't looking at moving to tup I'd probably go that route.  The only hurdle there is that execution of the script would either require the user to have special permissions or the script needs to be owned by a user with those special permissions & marked setuid so normal users can execute it.

-brian


reply via email to

[Prev in Thread] Current Thread [Next in Thread]