* Michael Biebl <[EMAIL PROTECTED]> [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. > 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. But make is run multiple times: Take a look at http://buildd.debian.org/fetch.cgi?&pkg=rsyslog&ver=3.18.2-1&arch=ia64&stamp=1218673256&file=log In line 150 there is the first debian/rules build call, which calls make in line 493. In line 774 there is the debian/rules binary-arch call, which calls make again in line 777 without need and touches build-stamp again in line 831 (as it does nothing in between, no harm is done but a few wasted buildd time, having a build-stamp stamp file when it cannot be used because of patch does not make much sense, though). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
