| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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')
|
|
|
|
|
|
| |
MinGW GCC seems to ignore LIBRARY_PATH which causes problem
when some libraries not using pkg-config were installed to
local directory
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]: https://github.com/raspberrypi/userland/commit/05d60a01d53dca363bb4286594db1826ffff8762
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit fae73079310eef9dce9737f2e37ff4b80c8830ee.
Before the waf build system was used, we had a configure script written
in shell. To drop the build dependency on Python, someone rewrote the
Python scripts we had to Perl. Now the shell configure script is gone,
and it makes no sense to have a build dependency on both Perl and
Python.
This isn't just a straight revert. It adds the new Matroska EBML
elements to the old Python scripts, adjusts the waf build system, and of
course doesn't add anything back needed by the old build system.
It would be better if this used matroska.py/file2string.py directly by
importing them as modules, instead of calling them via "python". But for
now this is simpler.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The test ended up failing if cuda.h wasn't present, even if cuda.h
isn't used during the actual build.
This test is attempting to establish if the ffmpeg being built
against has dynlink_cuda support. While it might theoretically be
possible to build against the older normally-linked-cuda version
of ffmpeg, it seems more trouble than it's worth.
|
| |
|
|
|
|
|
| |
This change will prevent annoying exceptions from
appearing when error messages are missing.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We always want to use __declspec(selectany) to declare GUIDs, but
manually including <initguid.h> in every file that used GUIDs was
error-prone. Since all <initguid.h> does is define INITGUID and include
<guiddef.h>, we can remove all references to <initguid.h> and just
compile with -DINITGUID to get the same effect.
Also, this partially reverts 622bcb0 by re-adding libuuid.a to the
build, since apparently some GUIDs (such as GUID_NULL) are not declared
in the source file, even when INITGUID is set.
|
|
|
|
| |
Signed-off-by: Josh de Kock <josh@itanimul.li>
|
| |
|
|
|
|
|
|
|
|
| |
For clang, it's enough to just put (void) around usages we are
intentionally ignoring the result of.
Since GCC does not seem to want to respect this decision, we are forced
to disable the warning globally.
|
|
|
|
| |
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
|
|
|
|
| |
This is necessary to make mpv build out of box on FreeBSD.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I got a report that the build on a recent aarch64 Linux kernel failed.
DVB support was detected, but errored on compilation:
In file included from ../stream/stream_dvb.c:57:0:
../stream/dvbin.h:72:5: error: unknown type name 'fe_bandwidth_t'
fe_bandwidth_t bw;
Make the test stricter, which should take care of this. (I couldn't find
out what exactly triggered the failure, nor could I attempt to reproduce
it.)
The change in stream/dvbin.h is to make sure that this isn't caused by
incorrect header inclusion. It now includes the same files as the
configure test.
|
|
|
|
| |
Fixes #2710
|
|
|
|
|
|
|
| |
Some packagers need to install default config files to some path but
automatically load system configuration files from another path.
See #2704
|
| |
|
|
|
|
|
|
| |
This sets the minimum supported Windows version to Windows Vista. The
subsystem version also affects some Windows API functions, including
GetSystemMetrics(SM_CXPADDEDBORDER).
|
|
|
|
|
|
|
|
|
|
| |
This is based on an older patch by James Ross-Gowan. It was rebased and
cleaned up. Also, the DWM API usage present in the older patch was
removed, because DWM reports nonsense rates at least on Windows 8.1
(they are rounded to integers, just like with the old GDI API - except
the GDI API had a good excuse, as it could report only integers).
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the GPU memcpy from the dxva2 code generally useful to other parts
of the player.
We need to check at configure time whether SSE intrinsics work at all.
(At least in this form, they won't work on clang, for example. It also
won't work on non-x86.)
Introduce a mp_image_copy_gpu(), and make the dxva2 code use it. Do some
awkward stuff to share the existing code used by mp_image_copy(). I'm
hoping that FFmpeg will sooner or later provide a function like this, so
we can remove most of this again. (There is a patch, bit it's stuck in
limbo since forever.)
All this is used by the following commit.
|
|
|
|
|
|
| |
Some particular checks can define the HAVE_ key on their own. To make sure
they work correctly when composed (with compose_checks) we force the HAVE_
key to be undefined if a check fails.
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
|
| |
|
|
|
|
|
|
|
|
|
| |
Until now, it only used the hash from the previous configure run,
instead of trying to get the latest hash. The "old" build system did
this correctly - we just have to use the existing logic in version.sh.
Since waf supports separate build dirs, extend version.sh with an
argument for setting the path of version.h.
|
|
|
|
|
|
|
| |
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's useless, and creates a bogus warning in subprocess-posix.c.
Since I don't know which compilers might have it by default, just change
it to -Wno-redundant-decls.
|
|
|
|
|
|
|
|
|
|
| |
Add a platform-specific entry-point for Windows. This will allow some
platform-specific initialization to be added without the need for ugly
ifdeffery in main.c.
As an immediate advantage, mpv can now use a unicode entry-point and
convert the command line arguments to UTF-8 before passing them to
mpv_main, so osdep_preinit can be simplified a little bit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
Starting to get tired of seeing the full config.h in verbose output
every time. Make it slightly more elegant by outputting the list of
satisfied dependencies instead.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
This warning wasn't overly helpful in the past, and warned against
perfectly fine code. But at least with recent gcc versions, this is the
warning that complains about assignments in if expressions (why???), so
we want to enable it.
Also change all the code this warning complains about for no reason.
|
|
|
|
|
|
|
| |
It is also used for initialization in channel-list setup.
Should fix compilation on FreeBSD, and is more correct
since it is used unconditionally.
Reverts 6445648 .
|
|
|
|
|
|
| |
A use of NO_STREAM_ID_FILTER was added to the DVB code recently. While I
have no idea what it's needed for, it makes mpv fail to compile on
FreeBSD 10.1. Add it to the dvb configure check.
|
|
|
|
|
| |
It's needed for the DisplayLink functions so it must be enabled for the basic
cocoa code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with waf 1.8.6 (in Python 3), the hcode variable isn't a
string, but a byte string.
This commit adds the solution proposed in the upstream waf bug report:
https://code.google.com/p/waf/issues/detail?id=1535
It seems a bit overly verbose, but on the other hand, this solution has
the chance of being most correct/compatible.
Fixes #1604.
|
|
|
|
|
|
|
|
| |
The compilation database is a JSON file[1] storing all compilation flags. That
is useful for tools using libclang for code completion and error reporting
(for example: YouCompleteMe for vim).
[1]: http://clang.llvm.org/docs/JSONCompilationDatabase.html
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't load all the legacy functions (including ancient extensions).
Slightly simplify function loader and context creation, now that legacy
GL doesn't need to be handled. Remove the code for drawing OSD in legacy
mode.
Remove all the header hacks, which were meant for ancient OpenGL headers
which didn't even support things like OpenGL 1.3. Instead, adjust the
GLX check to make sure we get both OpenGL 3x and 2.1 symbols. For win32
and OSX, we assume that the user has the latest headers anyway. For
wayland, we hope that things somehow go right.
|
|
|
|
|
|
|
| |
__STRICT_ANSI__ disables functions and definitions that aren't in ANSI
C. Unfortunately this includes j1(), which is used by the new
ewa_lanczos code. Cygwin's CFLAGS already unset __STRICT_ANSI__, but it
should be unset for both Cygwin and MinGW.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into
the build system, instead of defining them over and over in the code.
|
|
|
|
|
|
| |
We certainly don't use the mplayer configuration dir. The name didn't
matter, but now that it's in user-visible output (as part of config.h
being dumped in verbose mode), it's a bit too strange.
|
|
|
|
|
|
|
|
|
| |
It was requested that mpv should print what features etc. have been
enabled at compile time. It can print the configure command line, but it
obviously doesn't include autodetected features.
I tried to think of a nicer way than dumping the config.h as text, but
this was still the simplest way.
|
|
|
|
|
|
|
| |
Off by default, use --enable-win32-internal-pthreads .
This probably still needs a lot more testing. It also won't work on
Windows XP.
|
|
|
|
|
|
|
| |
The idea of using -Werror=format-security comes from MPlayer.
Try to use the compiler flags with any compiler. There's no reason not
to apply them on clang.
|
| |
|
|
|
|
| |
Same as with the VDA change.
|
|
|
|
|
| |
LuaJIT ships with a broken .pc file on OS X (see #1110), and leaving
Lua52 last was done only to improve libquvi interoperability.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Fixes #1164
|
|
|
|
|
|
| |
This warning makes absolutely no sense. Passing an empty string to
printf-like functions is perfectly fine. In the OSD case, it just sets
an empty message, practically clearing the OSD.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This is always included in the Xorg development headers. Strictly
speaking it's not necessarily available with other X implementations,
but these are hopefully all dead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr
extension to retrieve the refresh rate. Xrandr has the advantage that it
supports multiple monitors (at least the modern version of it).
For now, we don't attempt any dynamic reconfig |