Even if the patch provides an updated configure file the TestBot needs to be able to recreate it in case another patch does not provide it. Furthermore skipping the autoconf steps correctly is complex when a patchset changes configure.ac in part 1 and provides configure in part 2, or provides both in part 1 and only some other configure.ac change in part 2, etc. So it's better to just run autoconf whenever configure.ac is patched.
Signed-off-by: Francois Gouget fgouget@codeweavers.com ---
We could also decide to rerun autoconf even if only configure is updated. This may help detect patches that should have modified configure.ac instead but only if there is code that really needs the new configure (rather than disable some functionality as is usual). It would also defeat testing of configure changes following an autoconf update. So I'm not sure that would be better.
testbot/lib/Build/Utils.pm | 2 +- testbot/lib/WineTestBot/PatchUtils.pm | 4 ---- 2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/testbot/lib/Build/Utils.pm b/testbot/lib/Build/Utils.pm index 2fe7a9778..2e6cc853b 100644 --- a/testbot/lib/Build/Utils.pm +++ b/testbot/lib/Build/Utils.pm @@ -125,7 +125,7 @@ sub ApplyPatch($$) } }
- if ($Impacts->{Autoconf} && !$Impacts->{HasConfigure}) + if ($Impacts->{Autoconf}) { InfoMsg "\nRunning autoconf\n"; system("cd '$DataDir/$Dir' && set -x && autoconf"); diff --git a/testbot/lib/WineTestBot/PatchUtils.pm b/testbot/lib/WineTestBot/PatchUtils.pm index 4ce5bf40c..476757f38 100644 --- a/testbot/lib/WineTestBot/PatchUtils.pm +++ b/testbot/lib/WineTestBot/PatchUtils.pm @@ -317,10 +317,6 @@ sub GetPatchImpacts($;$) { $Impacts->{WineBuild} = $Impacts->{Autoconf} = 1; } - elsif ($Line =~ m=^--- \w+/configure$=) - { - $Impacts->{WineBuild} = $Impacts->{HasConfigure} = 1; - } elsif ($Line =~ m=^--- \w+/tools/make_makefiles$=) { $Impacts->{WineBuild} = $Impacts->{MakeMakefiles} = 1;