Hmm, I think the actual bug is in here:
# run standard sequence (this is faster)
$sequences{'install'} = [rules("build"), @i, rules("install-arch"),
rules("install-indep")];
It's really a hack to put the install-* targets after the whole @i
sequence of commands, and that is the source of the out of order
sequence that makes it jump ahead.
Do we even still need that hack? Perhaps not, now that dh doesn't
recursively call itself. This seems to be the case in what testing
I've been able to do with this patch (which also fixes this bug).
But I've misplaced any definative test cases for the massive slowdowns
the hack avoided..
diff --git a/dh b/dh
index 443d934..68f3d79 100755
--- a/dh
+++ b/dh
@@ -373,9 +373,6 @@ my @bd = qw{
dh_auto_build
dh_auto_test
};
-my @i_minimal = qw{
- dh_testroot
-};
my @i = qw{
dh_testroot
dh_prep
@@ -438,26 +435,10 @@ $sequences{'build-indep'} = [@bd];
$sequences{'build-arch'} = [@bd];
if (! compat(8)) {
# From v9, sequences take standard rules targets into account.
- if (rules_explicit_target('build-arch') ||
- rules_explicit_target('build-indep')) {
- # run sequences separately
- $sequences{build} = [@bd_minimal, rules("build-arch"),
rules("build-indep")];
- }
- else {
- # run standard sequence (this is faster)
- $sequences{build} = [@bd];
- }
+ $sequences{build} = [@bd_minimal, rules("build-arch"),
rules("build-indep")];
$sequences{'install-indep'} = [rules("build-indep"), @i];
$sequences{'install-arch'} = [rules("build-arch"), @i];
- if (rules_explicit_target('install-arch') ||
- rules_explicit_target('install-indep')) {
- # run sequences separately
- $sequences{'install'} = [rules("build"), @i_minimal,
rules("install-arch"), rules("install-indep")];
- }
- else {
- # run standard sequence (this is faster)
- $sequences{'install'} = [rules("build"), @i,
rules("install-arch"), rules("install-indep")];
- }
+ $sequences{'install'} = [rules("build"), rules("install-arch"),
rules("install-indep"), @i];
$sequences{'binary-indep'} = [rules("install-indep"), @b];
$sequences{'binary-arch'} = [rules("install-arch"), @ba, @b];
$sequences{binary} = [rules("install"), rules("binary-arch"),
rules("binary-indep")];
If the hack is still needed, it can be preserved, and the bug still
fixed, like this:
diff --git a/dh b/dh
index 443d934..8e2794f 100755
--- a/dh
+++ b/dh
@@ -453,13 +453,15 @@ if (! compat(8)) {
rules_explicit_target('install-indep')) {
# run sequences separately
$sequences{'install'} = [rules("build"), @i_minimal,
rules("install-arch"), rules("install-indep")];
+ $sequences{'binary-indep'} = [rules("install-indep"), @b];
+ $sequences{'binary-arch'} = [rules("install-arch"), @ba, @b];
}
else {
# run standard sequence (this is faster)
- $sequences{'install'} = [rules("build"), @i,
rules("install-arch"), rules("install-indep")];
+ $sequences{'install'} = [rules("build"), @i];
+ $sequences{'binary-indep'} = [rules("install"), @b];
+ $sequences{'binary-arch'} = [rules("install"), @ba, @b];
}
- $sequences{'binary-indep'} = [rules("install-indep"), @b];
- $sequences{'binary-arch'} = [rules("install-arch"), @ba, @b];
$sequences{binary} = [rules("install"), rules("binary-arch"),
rules("binary-indep")];
}
else {
That seems entirely safe to me, when install-arch/indep don't exist
there's no need to add them to the install sequence so long as
binary-arch/indep won't later try to run them.
--
see shy jo
signature.asc
Description: Digital signature
