Bernhard R. Link wrote: > * Michael Biebl <biebl@debian.org> [080915 02:50]: >>> Because patch is a phony target which is therefore always out of date, and >>> therefore anything that depends on patch will be triggered to run every >>> time that you run debian/rules. Depending on patch instead of >>> $(QUILT_STAMPFN) can therefore cause odd behavior like running configure >>> twice or make twice, depending on the rest of debian/rules. >>> >> Could you give a real-world example when that can happen. I've always >> used the patch target (instead of $(QUILT_STAMPFN)) in my debian/rules >> files and so far haven't encountered any issues. > > Actually, I think the "depending on the rest of debian/rules" is > incorrect, depending on "patch" always causes multiple invocations, not > only sometimes. > So to see the effects just take a lock at any build log of such a > package: > First look for debian/rules invocations. The important ones are build > and binary-arch. In the first there is configure and make invocation. > in the second there should usually (because of build*-patch) only be > one make install invocation and not extra make or configure invocation. > I you depend in patch instead of the stampfn there will be. Thanks Russ and Bernhard for your insightful comments! I guess one of the problems here is, that this magic $(QUILT_STAMPFN) variable is well hidden inside /usr/share/quilt/quilt.make and not documented anywhere (to a certain degree the same is true for dpatch. dpatch at least has some example files). What do you think, shouldn't the proper usage of this tools in debian/rules not be documented anywhere, README.Debian in quilt/dpatch maybe? Imho it's also not nice, that unlike the patch/unpatch targets, there is no common name for this stamp file variable, eg quilt uses QUILT_STAMPFN, dpatch DPATCH_STAMPFN. This makes it harder to switch a build system, as you musn't forget to update this variable. > >> Given that patch depends on $(QUILT_STAMPFN) I can't imagine a scenario >> where I would run into problems using the patch target. > > It causes build (and perhaps configure) to be run a second time in the > binary target. That usually is usually not a real problem but only wasted > cycles of the build daemons, but it makes the process more fragile. > The binary target is usually run in fakeroot or other things, so that > configure run there another time might for example include fakeroot's > LD_PRELOAD or other things to places where you do not want it. > > Looking around on your packages, most do not use patch directly. The > first I found that does (rsyslogd), has half of this problem and a > potential other problem: > > | config.status: configure > |[...] > | build-stamp: patch config.status > > This avoids the problem of runing configure again by telling make that > patch has not to be run before configure but in parallel (which usually > leads to it be run before, unless told to use multiple processors). > As you do not patch anything in the build system, that should not be an > problem here, though. > Thanks again, Bernhard. I didn't know that foo: bar baz will result in bar/baz run in parallel. I thought there is some kind of guarantee that bar is processed first. Would config.status: $(QUILT_STAMPFN) configure build-stamp: config-status be ok then? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature