On Thu, Sep 08, 2011 at 06:01:54PM -0400, Joey Hess wrote: > 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?
Right, using config.status as a stamp was (maybe is still ?) quite common. > dh avoids running dh_auto_configure more than once on its own. Is it doing so using *.debhelper.log ? What I have observed seem quite similar to the behaviour described in #604563, with "dh_auto_configure -a" being run for build-arch, and later "dh_auto_configure -i" being run for build-indep. Unless some special measures have been taken, like the one Roger suggested in http://bugs.debian.org/604563#20. > > 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. Argh :) Let's try to pinpoint where we misunderstand each other. * the "no magic" aspect implies that instead of talking "depends", which sorta implies {-binary,-arch,} targets, I should rather talk about "sequences", but still, sequences chain each other in a way that is not unlike make-targets dependencies, right ? * with this, is the "sequence chaining" I described, with {build,install,binary}{,-arch,-indep} correct ? Possibly not in the case of my "binary: binary-arch binary-indep" expectation, as demonstrated by the problem with my rules file below. Looks like an explanation of what "dh binary" really does would be helpful. * do you find the suggested test line above makes no sense ? At least I have found the idea quite useful in checking whether I had reached a usable stage in my build process. * anything else which did not look accurate ? > > |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. Yes, I see - my mind has probably been warped by build tookits in which we include Makefile snippets, and which can thus provide such "magic"... Feels like hitting some sort of limitation of the no-include approach (which has other advantages, I admit). > > * 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 Hm, I have made some progress, harnessing the debhelper log, with following debian/rules: | %: | dh $@ --parallel | override_dh_auto_configure: | dh_auto_configure -- -DCMAKE_SKIP_RPATH:BOOL=YES | build-arch: | dh $@ | docbook-to-man debian/tulip.sgml > debian/tulip.1 | build-indep: | $(MAKE) -C obj-* doc | install-indep: build-indep | dh_prep -i | mkdir -p debian/tmp/usr/share/doc/tulip-doc | set -e; for d in common userHandbook developerHandbook doxygen; do \ | cp -a obj-*/docs/$$d debian/tmp/usr/share/doc/tulip-doc/ ;\ | done | dh_auto_install -- -C docs | dh $@ | install-arch: build-arch | dh_prep -a | install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 | dh $@ | override_dh_install: | dh_install --fail-missing | override_dh_auto_clean: | dh_auto_clean | rm -f debian/tulip.1 Turns out it seems to work pretty well for binary-arch and binary-indep... except that dh_install fails to find the manpage... on its 3rd run. It gets run for -arch and -indep (without getting the -a or -i flag, BTW, did I miss something in my override ?, within easily identifiable sequences of dh_ commands that get passed -a and -i), and then a 3rd time within a sequence od dh_ commands that get passed -O--parallel, as part of target "binary" as shown by: | cp: cannot stat `debian/tmp/usr/share/man/man1/tulip.1': No such file or directory | dh_install: cp -a debian/tmp/usr/share/man/man1/tulip.1 debian/tulip//usr/share/man/man1/ returned exit code 1 | make[1]: *** [override_dh_install] Error 2 | make[1]: Leaving directory `/work/yann/deb/tulip/tulip-git' | make: *** [binary] Error 2 > > 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? Well, not exactly - but maybe summarizing the issues mentionned since OP would help, and we can either split this bugreport for those that surfaced since, or open new ones, as you prefer. But there are so many items here in the end, flooding the BTS might not be too constructive. I hope it is not too long as is, I have a nasty bias towards verbosity sometimes ;) - binary-arch/indep overrides not used under v8: notabug - binary-arch/indep overrides still not used under v9 (msg #37): need attempting to reproduce the config, since we ended up investigating other directions - me confused on the --no-act example (#47): manpage could mention that it only list the commands that would be run by "dh foo", that would be run with current state of the build tree. - Possibly missing the higher-level debugging tool I was dreaming of, that would tell what commands each of the dh calls would run without requiring the user to set his build tree to the state in which it would be when the tool will be run (with some luck this sentence will make sense to someone other than me ;). Not sure how that could be achieved - possibly relying on "make -dn" to see what commands would be run, and simulate how the succession of dh sequences will do, keeping track of the debhelper.log files - not a small task, I fear, and probably not without various problems. I guess this is the cost of handling sequencing outside of make... - the "dh_auto_configure run twice for -i and -a" issue discussed above - the related (at least in cmake case, did not investigate the autotools+dh situation yet) "how do I properly refer to obj-x86_64-linux-gnu/Makefile" for a rule that will run dh_auto_configure only once. That is, dh_auto_configure does a good job at using a separate builddir, but how do I access to that builddir from my rules file ? And a little more in dh_auto_configure.1 about what to expect (eg. a separate builddir, and for which build systems it uses one or not). Maybe indeed that sort of buildsystem-dependant info should go into specific manpages (eg. dh_buildsystem_cmake.7), since this in some way also impacts dh_auto_{make,install}. Note that access to the builddir can be useful for adding build-level commands (eg. manpage generation, which I curently send to debian/ and thus requires a specific dh_clean override, which would not be needed at all if I could generate it into the builddir) - the build-* override example should probably arrange for "dh $@" to be called (#62) - implications of the *.debhelper.log files should be described outside of the "internals" section, since they are important to sequencing (#62) - support for arch-specific overrides, or helpers to use arch/package specific in current overrides (as discussed in 604563 with Roger with his hook support patches) - (new topic inspired by reading 604563) it looked to me that providing pre_hooks, post_hooks, and per-dh_command envvar to pass extra flags could supercede override targets - and indeed, for the (as I guess) common case of overriding a target just for adding options, the envvar support could make the typical rules files even shorter. But if this has already been discussed, it may not be necessary to open such a wishlist. - maybe "dh <sequence>" should be taught to warn/bailout when it notices that a command it would have run has already been run, and its effect would be cancelled by dh_prep (or any other command if applicable), like in the "dh_auto_install before dh install-indep" you suggested in msg#67. - (new) when *-arch are not overriden, commands like "dh binary-arch --no-act" list commands that could be seen as "not really his", that is, commands that would be run by install-arch, and build-arch if they have not been run yet. Adding a note, maybe in the form of a #-commented line, telling that the following commands are part of the build-arch/install-arch/binary-arch set would help. Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
