On Sun, Aug 28, 2011 at 04:51:11PM -0400, Joey Hess wrote:
> Yann Dirson wrote:
> > Following the last example from the dh manpage, I am trying the
> > following rules file (compat=8).  However, it seems to completely
> > ignore the build-* overrides (install fails on manpage install):
> > 
> > $ dh build-arch --no-act
> >    dh_testdir -a
> >    debian/rules override_dh_auto_configure
> >    dh_auto_build -a
> >    dh_auto_test -a
> 
> So, looking at this again, I now see that you've misunderstood what
> dh does with explicit debian/rules targets.

Well, I was merely using it as suggested in the manpage:

       To see what commands are included in a sequence, without
       actually doing anything:

               dh binary-arch --no-act

An more detailed description of the meaning of "sequence" in the
synopsis, and the interactions with overridden targets like
build-arch, could probably have helped.

But probably I was confused by the example cited above, which simply
does not play well with overriding.

When one is going to override the standard targets, what would be
useful is to know what exact commands would be overridden.  Here
running "dh build-arch --no-act" shows configure/build/test commands;
although the status of the auto_configure command is clear to an
old-timer like me who is catching up with latest advances in packaging
tech, eg. the status of the auto_test command is not so: it looks like
it is run as part of the build-arch target proper, but then if I
override build-arch I need to re-specify dh_auto_test call
explicitely, which is a clear case of problem-inducing copypaste.

What about instead allow overriding commands with targets like
"override_dh_auto_build_indep" and "override_dh_auto_build_arch" ?


> The dh man page explains it this way -- I think this explaination is
> clear.
> 
>        Finally, remember that you are not limited to using
>        override targets in the rules file when using dh. You can
>        also explicitly define any of the regular rules file
>        targets when it makes sense to do so. A common reason to
>        do this is when your package needs different build-arch
>        and build-indep targets.  For example, a package with a
>        long document build process can put it in build-indep.
> 
>                #!/usr/bin/make -f
>                %:
>                        dh $@
> 
>                build-indep:
>                        $(MAKE) docs
>                build-arch:
>                        $(MAKE) bins
> 
>        Note that in the example above, dh will arrange for
>        "debian/rules build" to call your build-indep and build-
>        arch targets. You do not need to explicitly define those
>        dependencies in the rules file when using dh with
>        compatibility level v9.

I tried things like:

build-arch:
        dh_auto_build -a
        docbook-to-man debian/tulip.sgml > debian/tulip.1

That does not work, dh_auto_build does not do anything (nor does it
report anything under DH_VERBOSE=1).  If that's expected, maybe a
notice would be useful.

But it is unfortunate that it does not work, since that seems to
require reimplementing in my build-arch support for $buildpath and
--parallel (those that I need, probably among those I have not seen).

But trying to go that way:

build-arch:
        $(MAKE) -C obj-*
        docbook-to-man debian/tulip.sgml > debian/tulip.1

... it looks like the configure step is not run (which I would have
assumed from the last manpage example).


> With that said, if your package still doesn't build, perhaps there's
> still a bug somewhere..

... or I'm completely off-tracks :)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to