Yann Dirson wrote: > 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.
Special measures have been taken to avoid duplicate runs, but only when
running debian/rules binary.
Running back-to-back debian/rules binary-arch; debian/rules binary-indep
is not a common case and remains unoptimised IIRC.
> > > 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.
No, to quote Douglas Adams, it's entirely unlike tea.
The right mental model is that dh looks at what it's been asked to do,
looks at what has already been done, looks at the rules file, generates
a sequence of commands, and runs them.
> * 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.
I don't know what it's supposed to do. Running dh_clean manually is
sometimes useful, but I would not particularly suggest it as part of
some test regimen.
> It gets run for -arch and -indep (without getting the -a or -i flag,
> BTW, did I miss something in my override ?)
dh has to pass options into override targets via DH_INTERNAL_OPTIONS.
> 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. [...] as part of target "binary"
> | 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
I can't really debug it from this amount of information unfortunatly.
I don't know why it would be run 3 times, that does not seem like
a normal build situation.
> - binary-arch/indep overrides still not used under v9 (msg #37): need
> attempting to reproduce the config, since we ended up investigating
> other directions
| Unfortunately, switching to v9 here does not help - or ar least
| --no-act says so. I attach my current diff from the tulip 3.6.0dfsg-1
| currently in sid.
# no attachment actually attached
I don't see how this is a potential bug report, but then I'm not a mind
reader.
> - 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.
> - implications of the *.debhelper.log files should be described
> outside of the "internals" section, since they are important to
> sequencing (#62)
I'm always happy to make minor tweaks to man pages to eliminate
confusing wording. As long as I can find ways that does not bury the
user under a pile of obvious or irrelevant detail. File bugs.
> - 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...
dh should not need such a debugging tool. If it does, we should all go
back to long-form rules files, or more likely, someone is misusing dh,
or using it in a specific situation where it would make more sense to
use a long-form rules file.
> - 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}.
#601774
> - the build-* override example should probably arrange for "dh $@" to
> be called (#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)
#640965 covers both
> - (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.
I showed in 604563 why this would make rules files harder to maintain.
> - 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.
I prefer not to hardcode knowledge of what invidual debhelper
commands do into dh, and anyway it couldn't detect if some other
non-debhelper commands were run before dh_prep. I think it's better
to avoid people running such commands before running dh.
> - (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.
This is something I've wanted occasionally, though I just run dh
install-arch --no-act and compare. So feel free to file a bug, although
I am not actually sure it can be implemented due to the way dh builds
its sequences.
--
see shy jo
signature.asc
Description: Digital signature
