Yann Dirson wrote: > On Thu, Sep 08, 2011 at 04:09:42PM -0400, Joey Hess wrote: > > Yann Dirson wrote: > > > Hm, having configure step as part of the build actions, as opposed to > > > being actions of a configure-specific target like has been done since > > > a number of years, would probably be useful to mention in the dh > > > manpage. > > > > I'm not familiar with such a target. > > Well, the kind of "config.status" target, that precisely allows the > configure script to be run only once.
Isn't that mostly done as a stamp target, not a target to be called? dh avoids running dh_auto_configure more than once on its own. > Maybe mention (at least it is how I understand it) that <foo> depends > on both <foo>-binary and <foo>-arch, whether the ordering of -binary > and -arch is specified or if the user should avoid to rely on the > order, and if so a suggested test workflow to ensure that > (eg. dh_clean && debian/rules binary-arch && dh_clean && debian/rules > binary-indep - if you can confirm that is supposed to check what I > expect it to). > > And maybe insist on the fact that because of this, "binary" does not > depend on "build". I don't think that any of that is accurate, to the extent I understand what you're trying to say. > |install-arch: > | install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 > | dh $@ This doesn't work because dh is not magic; it cannot do anything before it is run. So make rules your install command, and then it runs dh, which finally gets a chance to ensure build-arch is run. > * I cannot insert my installs _after_ "dh $@", since dh_prep will nuke > it > * I cannot insert them _before_ it, since "dh_install" would run first > * I have no arch-specific override to put them where I'd like to > > gasp... did I find the reason to add those arch-specific overrides ? Possibly.. that would make a nice bug report. It's not what this bug report was about, is it? -- see shy jo
signature.asc
Description: Digital signature
