Roger Leigh wrote: > Another possibility to consider. Rather than overriding the various > dh_ commands with override, which is useful to invoke them with > extra/different options, it would be possible to additionally add > _hook or _local rules, possibly with _indep and _arch variants e.g. > dh_install_arch_hook to be run after dh_install. This prevents the > need for an override_dh_install. For example:
Sorry to say I see no need for this. It adds three more things have to
be learned to use dh. I purposefully want to keep dh's surface area as
small as possible.
The current override targets With your hooks, there is no
are nice because you can start common case to start off with.
off with an override that does What hook will be needed depends
not change behavior, and which on exactly what needs to be changed.
an editor can easily be taught
to insert:
dh_override_dh_foo:
dh_foo
And then you can from there maybe You hooks don't cover this, so
add an option to the command: the same override would be used
with them:
dh_override_dh_foo: dh_override_dh_foo:
dh_foo -Xbar dh_foo -Xbar
Maybe instead of the option you With your hooks, I have to remember
need to run something before; that _hook runs _after_ (and there's
it's obvious to anyone who knows nothing that runs before, so still
make how to change it to do that: cannot use them:
dh_override_dh_foo: dh_override_dh_foo:
something something
dh_foo dh_foo
And if you decide it needs to run Now I can use your hook, but I have
after instead, that's a single yank to change everything I had written:
and paste to do:
dh_override_dh_foo: dh_foo_hook:
dh_foo something
something
(And, looking at that, it's not really
clear in which order it and dh_foo run.)
Oh, I still needed that -X after Now I have to write another target,
all, of course it's trivial to put and I also have to consider whether
back: I can mix the _hook with the
override target.
dh_override_dh_foo: dh_override_dh_foo:
dh_foo -X dh_foo -X
something dh_foo_hook:
something
> override_dh_auto_install:
> ifneq (,$(shell dh_listpackages -a 2>/dev/null))
> $(MAKE) -C debian/build install DESTDIR=$(CURDIR)/debian/install
> endif
> ifneq (,$(filter schroot-common, $(shell dh_listpackages)))
> $(MAKE) -C debian/build/po install DESTDIR=$(CURDIR)/debian/install
> endif
>
> would become
>
> dh_auto_install_arch_hook:
> $(MAKE) -C debian/build install DESTDIR=$(CURDIR)/debian/install
>
> dh_auto_install_indep_hook:
> $(MAKE) -C debian/build/po install DESTDIR=$(CURDIR)/debian/install
At the moment we don't know for how many packages it will make sense
to do this splitting. It might be 0.1% for all I know. I'd rather wait
until there is a demonstrated wide need for a simpler syntax. Then there
would be other ways to simplify it, for example:
override_dh_auto_install:
dh_do -a -- $(MAKE) -C debian/build install
DESTDIR=$(CURDIR)/debian/install
dh_do -i -- $(MAKE) -C debian/build/po install
DESTDIR=$(CURDIR)/debian/install
--
see shy jo
signature.asc
Description: Digital signature
