I was converting some of my packages to use dh from the debhelper package, when I noticed that it doesn't support rerunning targets.
For example:
debian/rules build
to check a build.debian/rules build
again, and it does nothing.Or another common example I do:
fakeroot debian/rules binary
to check if I have everything installed in the package correctly.fakeroot debian/rules binary
to test out the change, and it does nothing.This is a big change in behavior from CDBS, which I was previously using. Is there a work around for this? I don't feel like running debian/rules clean
should be required in these situations.
debian/rules:
#!/usr/bin/make -f
export DEB_CXXFLAGS_MAINT_APPEND+=-std=gnu++0x
%:
dh $@
Yep, that's an intended and necessary behavior for dh
(it has to keep track of what steps it has taken already, because it will usually be invoked several times over the course of a full package build and it can't leverage the internals of make
to keep state. It's kind of a terrible hack, but it is a decent solution given the terrible problem constraints).
To be fair, it hasn't ever been well-defined what debian/rules build
is supposed to do when there's already a partial build. If a build has succeeded previously and no state has been cleared, it's not unreasonable for Debhelper to treat the build as done.
It might be a solution to your problem just to use dh_clean
when you want to start a build over. That won't invoke dh_auto_clean
, so if your code gets built outside of the debian/
directory, it won't be touched, but the Debhelper state will be cleaned.
If instead you want to be able to "rewind" the partial debhelper build so that it thinks a build hasn't yet been done, you might try using a script that does something like
#!/bin/bash
sed -i -e '/dh_auto_build/,$ d' debian/*.debhelper.log
That will remove the "dh_auto_build
" entry and everything after it from any *.debhelper.log build state, so that dh
will think they haven't been done. Any steps it took up to that point will still be considered done.