Bug#429723: [dpatch-maintainers] Bug#429723: Undocumented sideeffect of forcing build to run
Hi, > Actually not, it seems I must have had the stamp file dependancy still > in place when testing the .PHONY way, as it doesn't work when I test it > now. > > Here's a relatively stripped-down version of the makefile I'm having > problems with. > > To reproduce, just create an empty configure.ac in the same directory, > and try "make -f rules build" twice. > > Then swap the comment between the following lines: > > #config.status: patch-stamp configure.ac > config.status: patch configure.ac After re-reading code and samples, it's the manpage in error. The 'sample' file does it correctly and uses patch-stamp. The manpage has been outdated. regards, junichi -- [EMAIL PROTECTED],debian.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429723: [dpatch-maintainers] Bug#429723: Undocumented sideeffect of forcing build to run
Hi, > > > > > > Either way, I think it should be documented. > > > > Where could it be documented as to be effective? > > The very nice "SIDE EFFECTS" section of the dpatch.make manpage? :) Heh, that's good :) regards, junichi -- [EMAIL PROTECTED],debian.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429723: [dpatch-maintainers] Bug#429723: Undocumented sideeffect of forcing build to run
On Wed, Jun 20, 2007 at 05:26:20AM +0900, Junichi Uekawa wrote:
> Hi,
>
> > Looking at the code, I'm a bit confused.
> > It looks like this:
> >
> > patch: patch-stamp (well, ${DPATCH_STAMPFN})
> > patch-stamp:
> > XX
> > XX
> >
> >
> > So, if patch is .PHONY, patch-stamp is a real file, depending on
> > 'patch' should do the right thing (only be invoked if patch-stamp does
> > not exist), and depending on patch-stamp shouldn't be necessary.
> > At least, this is the intention.
> >
> > Could you give me a testcase / log ?
>
> So, after a face-to-face discussion, it seems like the problem was
> dpatch.make did not set 'patch', and 'unpatch' as .PHONY.
Actually not, it seems I must have had the stamp file dependancy still
in place when testing the .PHONY way, as it doesn't work when I test it
now.
Here's a relatively stripped-down version of the makefile I'm having
problems with.
To reproduce, just create an empty configure.ac in the same directory,
and try "make -f rules build" twice.
Then swap the comment between the following lines:
#config.status: patch-stamp configure.ac
config.status: patch configure.ac
do a "make -f rules clean" and retry "build" twice again.
--
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
#!/usr/bin/make -f
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.
# Adapted for ekg2 package by Marcin Owsiany.
# GNU copyright 2002-2006
#export DH_VERBOSE=1
# Help cross-compiling
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
# This is to ease debugging, until ekg2 stabilizes
DEB_BUILD_OPTIONS=nostrip
export DEB_BUILD_OPTIONS
CFLAGS += -g
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
export CFLAGS
# dh_strip will take care of nostrip
AUTOMAKE = automake-1.9
ACLOCAL = aclocal-1.9
export AUTOMAKE ACLOCAL
include /usr/share/dpatch/dpatch.make
.PHONY: patch
#config.status: patch-stamp configure.ac
config.status: patch configure.ac
@echo autogen
touch config.status
build: build-stamp
build-stamp: config.status
@echo make
touch build-stamp
clean: clean-patched unpatch
clean-patched:
rm -f build-stamp
rm -f config.status
@echo make clean
install: build
@echo make install
binary-indep: build install
# We have nothing to do.
binary-arch: build install
@echo build deb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install
Bug#429723: [dpatch-maintainers] Bug#429723: Undocumented sideeffect of forcing build to run
Hi,
> > > Consider a standard case of dpkg-buildpackage invoking "build" first and
> > > then "binary" next.
> > >
> > > Adding a dependancy on "patch" to one's "build" or "configure" (or
> > > whatever) target, causes this target to be re-run even when not strictly
> > > necessary, during the second invocation.
> > >
> > > Replacing "patch" with "dpatch-stamp" fixes the issue for me, but is
> > > bound to break if dpatch.make changes behavior at some point to do
> > > something important in the "patch" target (other than depending on the
> > > stamp file).
> > >
> > > I don't know if it can be fixed easily, other than recommending to
> > > depend on "dpatch-stamp" rather than "patch".
> > >
> > > Either way, I think it should be documented.
Looking at the code, I'm a bit confused.
It looks like this:
patch: patch-stamp (well, ${DPATCH_STAMPFN})
patch-stamp:
XX
XX
So, if patch is .PHONY, patch-stamp is a real file, depending on
'patch' should do the right thing (only be invoked if patch-stamp does
not exist), and depending on patch-stamp shouldn't be necessary.
At least, this is the intention.
Could you give me a testcase / log ?
regards,
junichi
--
[EMAIL PROTECTED],debian.org}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429723: [dpatch-maintainers] Bug#429723: Undocumented sideeffect of forcing build to run
Hi,
> Looking at the code, I'm a bit confused.
> It looks like this:
>
> patch: patch-stamp (well, ${DPATCH_STAMPFN})
> patch-stamp:
> XX
> XX
>
>
> So, if patch is .PHONY, patch-stamp is a real file, depending on
> 'patch' should do the right thing (only be invoked if patch-stamp does
> not exist), and depending on patch-stamp shouldn't be necessary.
> At least, this is the intention.
>
> Could you give me a testcase / log ?
So, after a face-to-face discussion, it seems like the problem was
dpatch.make did not set 'patch', and 'unpatch' as .PHONY.
The 'simple' solution looks like to set patch and unpatch as .PHONY.
I'm not sure how many packages already depend on this behavior, but
hopefully it won't break too many things.
regards,
junichi
--
[EMAIL PROTECTED],debian.org}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429723: [dpatch-maintainers] Bug#429723: Undocumented sideeffect of forcing build to run
On Wed, Jun 20, 2007 at 04:22:57AM +0900, Junichi Uekawa wrote: > Hi, > > > Consider a standard case of dpkg-buildpackage invoking "build" first and > > then "binary" next. > > > > Adding a dependancy on "patch" to one's "build" or "configure" (or > > whatever) target, causes this target to be re-run even when not strictly > > necessary, during the second invocation. > > > > Replacing "patch" with "dpatch-stamp" fixes the issue for me, but is > > bound to break if dpatch.make changes behavior at some point to do > > something important in the "patch" target (other than depending on the > > stamp file). > > > > I don't know if it can be fixed easily, other than recommending to > > depend on "dpatch-stamp" rather than "patch". > > > > Either way, I think it should be documented. > > Where could it be documented as to be effective? The very nice "SIDE EFFECTS" section of the dpatch.make manpage? :) -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429723: [dpatch-maintainers] Bug#429723: Undocumented sideeffect of forcing build to run
Hi, > Consider a standard case of dpkg-buildpackage invoking "build" first and > then "binary" next. > > Adding a dependancy on "patch" to one's "build" or "configure" (or > whatever) target, causes this target to be re-run even when not strictly > necessary, during the second invocation. > > Replacing "patch" with "dpatch-stamp" fixes the issue for me, but is > bound to break if dpatch.make changes behavior at some point to do > something important in the "patch" target (other than depending on the > stamp file). > > I don't know if it can be fixed easily, other than recommending to > depend on "dpatch-stamp" rather than "patch". > > Either way, I think it should be documented. Where could it be documented as to be effective? regards, junichi -- [EMAIL PROTECTED],debian.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
