From 94b80da14fbca1296ac744a53581b817ae56d370 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)" <avihpit@yahoo.com>
Date: Wed, 1 Aug 2018 09:06:36 +0300
Subject: [PATCH] configure: unique(): fixup to restore original output order
Originally unique() was keeping the last occurence of each non-unique
item, but commit XXX changed it to keep the first.
This commit restores the original order due to *TBD*.
---
configure | 13 +++++++++++++
1 file changed, 13 insertions(+)
@@ -850,14 +850,27 @@ prepend(){
eval "$var=\"$* \$$var\""
}
+reverse () {
+ eval '
+ reverse_out=
+ for v in $'$1'; do
+ reverse_out="$v $reverse_out"
+ done
+ '$1'=$reverse_out
+ '
+}
+
+# keeps the last occurence of each non-unique item
unique(){
unique_out=
eval unique_in=\$$1
+ reverse unique_in
for v in $unique_in; do
# " $unique_out" +space such that every item is surrounded with spaces
case " $unique_out" in *" $v "*) continue; esac # already in list
unique_out="$unique_out$v "
done
+ reverse unique_out
eval $1=\$unique_out
}
--
2.17.1
For overview see: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233665.html Attached is patch 1/3 which was at "main.patch" of that message. About 50-70% of configure runtime was being spent inside one function: flatten_extralibs() and callees resolve() and unique(). It manipulates strings and invoked nearly 20K (20000) subshells. It was rewritten to avoid subshells, and ended up x50-x250 faster. unique() now outputs a different order: it was keeping the last instance of recurring items, now it keeps the first. It affects libs order at ffbuild/config.{mak,sh} - but I don't think it matters. If it does, "opt1-reorder-unique.patch" restores the original order. Let me know if/why it matters and I'll squash it and update the commit message accordingly if required. On Saturday, August 25, 2018 7:55 PM, Timo Rothenpieler <timo@rothenpieler.org> wrote: Please use git send-email to send your patches, or at least send each patch, created by git format-patch, as individual attachment. Your files seem to contain multiple patches one after another, which makes them very hard to follow. But nice work! Let's hope this does not cause any regressions.