diff options
author | Avi Halachmi (:avih) <avihpit@yahoo.com> | 2018-08-28 17:14:55 +0300 |
---|---|---|
committer | James Almer <jamrial@gmail.com> | 2018-10-08 21:01:24 -0300 |
commit | 3fb09dba40b0d0a67272af8f7995638eaea3f9a4 (patch) | |
tree | 388a3d59b9ee7e3cab2a96bc2ab86dd87e43fd5b /libavcodec/alpha/idctdsp_alpha.c | |
parent | a634da282b7c5963d69a0c9105436e55382a5ccb (diff) | |
download | ffmpeg-3fb09dba40b0d0a67272af8f7995638eaea3f9a4.tar.gz |
configure: <fflib>_deps: validate, reduce sensitivity
- Allow to add deps in any order rather than "in linking order".
- Expand deps chains as required rather than just once.
- Validate that there are no cycles.
- Validate that [after expansion] deps are limited to other fflibs.
- Remove expectation for a specific output order of unique().
Previously when adding items to <fflib>_deps, developers were
required to add them in linking order. This can be awkward and
bug-prone, especially when a list is not empty, e.g. when adding
conditional deps.
It also implicitly expected unique() to keep the last instance of
recurring items such that these lists maintain their linking order
after removing duplicate items.
This patch mainly allows to add deps in any order by keeping just
one master list in linking order, and then reordering all the
<fflib>_deps lists to align with the master list order.
This master list is LIBRARY_LIST itself, where otherwise its order
doesn't matter.
The patch also removes a limit where these deps lists were expanded
only once. This could have resulted in incomplete expanded lists,
or forcing devs to add already-deducable deps to avoid this issue.
Note: it is possible to deduce the master list order automatically
from the deps lists, but in this case it's probably not worth the
added complexity, even if minor. Maintaining one list should be OK.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Diffstat (limited to 'libavcodec/alpha/idctdsp_alpha.c')
0 files changed, 0 insertions, 0 deletions