When mpv is being linked against static libraries which have shared
libraries as dependencies, linker will throw error because pkg-config
with --static flag will return shared libraries which will be placed
under the -Wl,-Bstatic section, while pkg-config without --static flag
will omit the private libraries required to link the static library.
With this function users can modify the wscript to insert the dependencies
when necessary. For example, linking FFmpeg with shared OpenSSL and zlib:
'func': check_pkg_config_mixed(['crypto','ssl','z'], 'libavcodec')
Upstream provides pkgconfig files for quite some time now [1,2].
Use them to determine the required flags instead of hard coding.
This makes cross-compilation easy, which I dare to say is important for
many raspberry-pi users. This also prevents picking libEGL and libGLESv2
from mesa when they are present, which can happen with the current code.
Good distros should put these pkgconfig files into default pkg-config
search path or populate PKG_CONFIG_PATH for users. However, be nice to
everybody and manually look into '/opt/vc/lib/pkgconfig' just in case.
Hence the PKG_CONFIG_PATH mangling.
[1]: https://github.com/raspberrypi/userland/issues/245
[2]: 05d60a01d5
Arch linux is about to update to lua 5.3.x, but lua 5.2.x will be
provided by package lua52, which contains pkg-config file lua52.pc.
Signed-off-by: wm4 <wm4@nowhere>
It simply doesn't work, and is hard to make work. Lua 5.3 is a different
language from 5.1 and 5.2, and is different enough to make adding
support a major issue. Most importantly, 5.3 introduced integer types,
which completely mess up any code which deals with numbers.
I tried to make this a compile time check, but failed. Still at least
try to avoid selecting the 5.3 pkg-config package when the generic "lua"
name is used (why can't Lua upstream just provide an official .pc
file...). Maybe this actually covers all cases.
Fixes#1729 (kind of).
Using check_statement() with an empty statement just to check for the
header is quite a hack. Fix check_headers() (so it takes a "use"
parameter), and use it for the checks instead.
We now use threads and other pthread API a lot, and not always we use it
from threads created with pthread_create() (or the main thread). As I
understand, with static linking we would have to use
pthread_win32_thread_attach/detach_np() every time we enter or leave a
foreign thread. We don't do this, and it's not feasible either, so it's
just broken.
This still should work with dynamic pthreads-win32. The MinGW pthread
implementation should be unaffected from all of this.
We need to manually define the flag since we are using a separate identifier
for each of the Lua checks. This was done before 9b45b48 by the composed check
with a define_key (see waftools/checks/generic.py).
The pkg-config check was the only one to not redefine a define key because Waf
already does that automatically when we call the generated function with the
same identifier as the generator function. Now if they are called with two
different arguments we will get two different definitions.
Fixes#1218
No development activity (or even any sign of life) for almost a year.
A replacement based on youtube-dl will probably be provided before the
next mpv release. Ask on the IRC channel if you want to test.
Simplify the Lua check too: libquvi linking against a different Lua
version than mpv was a frequent issue, but with libquvi gone, no
direct dependency uses Lua, and such a clash is rather unlikely.
This wraps waf's find_program in our own check boilerplate code so that it
can be used in the declarative dependencies section of the wscript.
Can be used like this:
}, {
'name': 'sed',
'desc': 'sed program',
'func': check_program('sed', 'SED'),
}, {
First argument is the program name, and the second is the waf variable name
where the program path will be stored. In this example we will be able to
refer to sed with ${{SED}} when creating waf Tasks in wscript_build.
/cc @giselher: I think you need this for wayland-scanner.
Our code currently tries to link -lpthread and adds stuff like -D_REENTRANT
based on the target platform.
GCC actually supports to just pass a -pthread compiler and linker flag that
will automatically enable threading and define the correct symbols for the
platform, so let's try to just use that as our first choice.
clang also supports -pthread but it must be used only as a compiler flag,
so we also take care of that scenario with this commit.
If sys/soundcard.h is actually linux/soundcard.h then it supports only OSSv3
API. This may happen when OSSLIBDIR == /usr while forgetting to replace
sys/soundcard.h from glibc.
However, after fa620ff waf prefers native implementation which is inferior
on Linux. To fix try making waf prefer oss-audio-4front. It's quite unusual
to have 4Front OSS installed where native implementation is superior, anyway.
Signed-off-by: bugmen0t <@>
Make the false positives path also undef the 4Front define.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
Fixes#396
This prevents waf from running test programs after compilation. A better
approach would be to only remove this option if the check actually errors,
but we are using this only for Lua anyway.
The OSS checks were a big mess and quite buggy. This reimplementes them using
a declarative approach and clearly distinguishing between the various OSS
implementations. The code should now almost be auto-documenting.
We currently support the following implementations of OSS:
* platform-specific (with `sys/soundcard.h`)
* SunAudio (default on NetBSD and useable on OpenBSD even if we have sndio
support there).
* 4Front (default on FreeBSD)
Since now each OSS check also checks for the appropriate soundcard header,
remove the old soundcard check.
Many thanks to @bugmen0t for in depth info about all the BSDs.
Check #380 and #359 for more info on this commit.
Original commit was implemented differently by @bugmen0t. The problem here was
that the waf API was called directly, instead of using our own check_cc (which
defaults, among other things, to non mandatory checks).
- without Utils.* always returns empty string
- subprocess doesn't need extra quoting for sh -c
- "source" is a bash'ism, not in POSIX sh
- most shell commands embed newline at the end
waf apparently only appends a pkgconfig flag if it doesn't already exist in
the lib storage. Since our configure often checks for multiple libraries in
one call we want to keep the flags as is. This is especially important to
always keep stuff like -lm in the right place.
This commit adds a new build system based on waf. configure and Makefile
are deprecated effective immediately and someday in the future they will be
removed (they are still available by running ./old-configure).
You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`.
TL;DR: we couldn't get the same level of abstraction and customization with
other build systems we tried (CMake and autotools).
For guidance on how to build the software now, take a look at README.md
and the cross compilation guide.
CREDITS:
This is a squash of ~250 commits. Some of them are not by me, so here is the
deserved attribution:
- @wm4 contributed some Windows fixes, renamed configure to old-configure
and contributed to the bootstrap script. Also, GNU/Linux testing.
- @lachs0r contributed some Windows fixes and the bootstrap script.
- @Nikoli contributed a lot of testing and discovered many bugs.
- @CrimsonVoid contributed changes to the bootstrap script.
