Commit a8968b1425 made the build and check targets depend on devprogs,
but no rule defines devprogs, so make build and make check stop with
"No rule to make target 'devprogs'". Define it like testprogs, from
the DEVPROGS of each library, and mark it phony.
Signed-off-by: lusoris <lusoris@proton.me>
This reverts commit 59dd21047e.
The new tool does not properly resolve relative paths on MSYS2, and
potentially other targets.
It tries to make paths relative that are outside of the virtual MSYS
root dir, trying to .. below it. Resulting in invalid paths that send
MSYS make into an infinite loop somehow.
Previously each object was effectively compiled twice: once with
-showIncludes -Zs just for the dependencies, and once for real. Pass
-showIncludes on the actual compilation instead and let the mscl helper
convert the include records into the .d file.
make -j32 with MSVC 2026:
before:
1:40.35 elapsed, 345 s user+sys
after:
0:59.86 elapsed, 124 s user+sys
no .d generation:
0:59.66 elapsed, 129 s user+sys
making dependency generation nearly free.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Nothing has produced .ho files since dfd9159f3d in 2012, when
checkheaders switched to compiling wrapper .c files.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The INSTALL pretty-printer echoed the rule prerequisites ($^), which
printed duplicate and phony names and never showed the destination.
Convert the install recipes to an INSTALL_FILES helper that receives the
install options, source files and destination as separate arguments. In
quiet mode it prints one "source -> destination" line per installed
file.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
These tools run on the target and are supposed to be used
for development; they are basically the same as TESTPROGS,
just without the presumption of living in the tests
subdirectory.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use $(SRC_PATH), the source tree root, for consistent
repository-relative paths. SRC_DIR used before was undefined and this
macro only stripped leading /.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Otherwise, occasional build races have been observed:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/3001/steps/13/logs/stdio
/bin/sh: 4: cannot create fftools/resources/graph.css.min: Directory nonexistent
mkdir -p fftools/graph
/bin/sh: 1: cannot create fftools/resources/graph.html.gz: Directory nonexistent
make: *** [/srv/pokybuild/.../ffmpeg-8.0.1/ffbuild/common.mak:165: fftools/resources/graph.html.gz] Error 2
make: *** Waiting for unfinished jobs....
make: *** [/srv/pokybuild/.../ffmpeg-8.0.1/ffbuild/common.mak:145: fftools/resources/graph.css.min] Error 2
There's a separate rule for making those directories, but unfortunately
it's racing with the rules that expect the directories to exist. Rather
than add a Makefile dependency, I've injected the dir creation directly
into the commands that can otherwise fail - a proper fix would probably
add the rule rather.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
This fixes generating shared libraries with a toolchain that requires
makedef (MSVC, or mingw toolchains with LLD, that lacks support for
--version-script).
This uses the existing response file generated for linking, by
splitting out the choice of input parameter to makedef to a variable
expanded by make.
This avoids relying on "echo" within makedef supporting long command
lines; msys2/cygwin shells handle it fine, while busybox doesn't.
Since 9e857e1f8a, library.mak generates a
response file containing the list of input object files. This was done
to avoid hitting the 8192 character command line limit on Windows
shells.
However, that particular solution still relies on emitting a
very long `echo` command that gets delegated to a subshell. This means
that, for example, running `make` within problematic shells like Git
Bash could still hit the command line length limit when this `echo` step
is ran. Other MSYS2 shells are not affected, meaning the previous
workaround only helped when running in an MSYS2 environment, but broke
when using Git Bash, e.g. for MSVC. This primarily affected `libavcodec`
due to the sheer volume of files contained within.
To avoid this problem, this commit changes the object emission step to
use GNU make's `file` builtin to write the list of object files. `file`
itself was introduced in GNU Make 4.0, but FFmpeg still supports old
versions--notably Apple's ancient Make 3.81--so for older make versions
that don't support this, the old echo subshell is used. This tradeoff
should be fine since it's trivial to grab a new-enough Make on Windows,
and other platforms that may be stuck with ancient Make versions
shouldn't have nearly as restrictive command line limits.
Signed-off-by: crueter <crueter@eden-emu.dev>
Commit c6c8063186 added getters for them.
Also remove av_export_avutil and the BUILDING_foo macro.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Rather than hard-coding a separate set of NASM macros, or generating them
with a separate function, we can just leverage the C preprocessor to generate
a NASM source file *from* the existing ops macros.
This is maybe a bit unorthodox, but it avoids unnecessary overhead from
re-generating the macros twice, avoids manual updating of the NASM macros,
and generally does not come with any real downside except being a bit ugly.
The main source of ugliness is the fact that the C preprocessor expands
everything into a single line, whereas NASM expects separate statements to
be on separate lines. Very fortunately, we can work around this by writing a
another NASM macro to take its arguments and dump them onto multiple lines.
It may seem premature, but I went ahead and defined all the macros, since
it was easy enough to do.
I added the %include in this commit to trigger build errors that occur only
as a result of introducing this file in the same commit that introduces it.
Signed-off-by: Niklas Haas <git@haasn.dev>
This commit pieces together the previous few commits to implement the
NEON backend for sws_ops.
In essence, a tool which runs on the target (sws_ops_aarch64) is used
to enumerate all the functions that the backend needs to implement. The
list it generates is stored in the repository (ops_entries.c).
The list from above is used at build time by a code generator tool
(ops_asmgen) to implement all the sws_ops functions the NEON backend
supports, and generate a lookup function in C to retrieve the assembly
function pointers.
At runtime, the NEON backend fetches the function pointers to the
assembly functions and chains them together in a continuation-passing
style design, similar to the x86 backend.
The following speedup is observed from legacy swscale to NEON:
A520: Overall speedup=3.780x faster, min=0.137x max=91.928x
A720: Overall speedup=4.129x faster, min=0.234x max=92.424x
And the following from the C sws_ops implementation to NEON:
A520: Overall speedup=5.513x faster, min=0.927x max=14.169x
A720: Overall speedup=4.786x faster, min=0.585x max=20.157x
The slowdowns from legacy to NEON are the same for C/x86. Mostly low
bit-depth conversions that did not perform dithering in legacy.
The 0.585x outlier from C to NEON is gbrpf32le -> gbrapf32le, which is
mostly memcpy with the C implementation. All other conversions are
better.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Right now, CFLAGS like -std=c17 leak onto the C++ compilers commandline,
leading to tons of warnings and even some errors.
Undefining __STRICT_ANSI__ causes strong warnings from the stdlib
headers. So only set it for C.
The SLIBOBJS variable was introduced in 56572787ae but is no longer used.
Another variable, SHLIBOBJS, was introduced after SLIBOBJS, in 20b0d24c2f.
The functionality from SLIBOBJS was effectively migrated to SHLIBOBJS in b77fff47d0.
No code has used SLIBOBJS since.
This commit removes all remaining references to SLIBOBJS from the build system.
Compression requires zlib to be available, otherwise resources will
be included uncompressed - in either case via BIN2C.
It can also be disabled via
./configure --disable-resource-compression
Size figures:
graph.css 7752
graph.css.min 6655 (css is always minified)
graph.html 2153
No Compression
graph.css.c 40026
graph.css.o 9344 (6688)
graph.html.c 13016
graph.html.o 4848 (2186)
With Compression
graph.css.c 10206
graph.css.o 4368 (1718)
graph.html.c 5725
graph.html.o 3632 (971)
Numbers in brackets: .rodata size from 'size -Ax -d *.o'
Signed-off-by: softworkz <softworkz@hotmail.com>
The linker command can exceed the maximum argument limit on MinGW,
especially for libavcodec.
The objects list is now stored in a file and passed to the linker.
And add wasm simd128 flag, so we can add simd128 optimizations.
It can be enabled by put -msimd128 to extra cflags. There is
no runtime detection on simd128 support yet. I think that needs to
be done with JavaScript.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The implicit interpreter is dependent on the environment, and isn't
guaranteed to be /bin/sh. Some packagers call this script directly, and
in certain environments such as containers using qemu-user through
binfmt_misc emulation on Linux it doesn't fallback to /bin/sh.
To fix these cases we add the interpreter explicitly.
Signed-off-by: J. Dekker <jdek@itanimul.li>
In some builds, the following object files could be left behind
after make clean:
./libavfilter/metal/utils.o
./libavfilter/metal/vf_yadif_videotoolbox.metallib.o
./libavcodec/x86/h26x/h2656dsp.o
./libavcodec/neon/mpegvideo.o
./ffbuild/bin2c_host.o
Fixes: http://trac.ffmpeg.org/ticket/10895
Signed-off-by: Martin Storsjö <martin@martin.st>
Without this flag, timestamps were embedded into the final
binary if CUDA was enabled.
Signed-off-by: Rob Hall <robxnanocode@outlook.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Currently, $(CPPFLAGS) and $(CFLAGS) are prepended to CXXFLAGS
(the flags for compiling C++) like this:
CXXFLAGS := $(CPPFLAGS) $(CFLAGS) $(CXXFLAGS)
Using ":=" creates a simply expanded variable, i.e. the values
of the variable at the time of assignment are used and later
modifications to them are ignored (using a recursively expanding
variable (i.e. "=" instead of ":=") is not really possible here,
as there would be an infinite loop when evaluating CXXFLAGS).
Yet we perform later additions to CPPFLAGS: HAVE_AV_CONFIG_H and
BUILDING_libfoo are defined. These do not reach C++ compilations.
To fix this a trick is employed to prepend to a recursively
expanded variable while keeping it recursively expanded.
There are two practical consequences of this: C++ files now no longer
include the version.h header, but only the version_major.h header
of their library, saving some recompilations. Furthermore, they
now get some optimized math functions (namely the ones from
lavu/intmath.h instead of the ones from lavu/common.h).
(av_parity() is the only one for which it makes a difference.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
lusoris