| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Remove waf entirely in favor of meson as the only supported build
system. Waf was officially deprecated in 0.36.0, and has not been
preferred over meson since 0.35.0.
|
| |
|
|
|
| |
1.27 would have been nicer but ubuntu 22.04 is on 1.25 so we'll just
compromise.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This returns the value of the target OS that mpv was built on as
reported by the build system. It is quite conceivable that script
writers and API users would need to make OS-dependent choices in some
cases. Such people end up writing boilerplate/hacks to guess what OS
they are on. Assuming you trust the build system (if you don't, we're in
really deep trouble), then mpv actually knows exactly what OS it was
built on. Simply take this information at configuration time, make it a
define, and let mp_property_platform return the value.
Note that mpv has two build systems (waf and meson), so the names of the
detected OSes may not be exactly the same. Since meson is the newer
build system, the value of this property follows meson's naming
conventions*. In the waf build, there is a small function to map known
naming deviations to match meson (i.e. changing "win32" to "windows").
waf's documentation is a nightmare to follow, but it seems to simply
take the output of sys.platform in python and strip away any trailing
numbers if they exist (exception being win32 and os2)*.
*: https://mesonbuild.com/Reference-tables.html#operating-system-names
*: https://waf.io/apidocs/Utils.html#waflib.Utils.unversioned_sys_platform
|
| |
|
|
|
| |
It's three lines. There's no real reason to have this as a separate file
when we've removed every other compile check sourced from outside files.
|
| |
|
|
|
| |
Previously, we did this doing code fragments, but we can be a bit more
clever and use has_function as well as the platform we're on.
|
| |
|
|
|
|
| |
Adds support for the meson build system as well as a bit of
documentation. Compatibility with the existing waf build is
maintained.
|
| |
|
|
|
| |
This can be used to do things like query the values of preprocessor
defines like version macros, among other potential uses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TL;DR: use --lua=XXX for pkg-config name XXX, e.g. --lua=lua-5.1 .
For unversioned 'lua.pc', use the name luadef51/luadef52 .
Autodetection remains the same (5.2 names, luajit, 5.1 names).
The old names are still supported, but not auto-detected.
Before this patch, if one wanted to choose a specific lua version when
more than one is installed, then the names were a mess, e.g. 51obsd is
also the name detected on Arch linux, and other (distro) names are
also not unique to a specific distro/platform.
So to ask mpv to choose the package name (specifically, the pkg-config
file name), one needs to look at the mpv sources and find the
(arbitrary) distro name which has the same lua version naming as they
do on their own system, e.g. --lua=51obsd on Arch. This is a pain.
Now we add generic names:
- luadef51/luadef52 - generic pkg-config lua.pc (version is inside).
- lua* - exactly the pkg-config name, e.g. --lua=lua-51 for lua-51.pc
(the names are curated, e.g. --lua=foo won't detect foo.pc).
- The legacy names (e.g. 51deb) are still supported, but undocumented,
and the new generic names take precedence during auto-detection.
The fact that the generic names all start with "lua" has an additional
benefit that it shows right after "lua" at the output of mpv -v,
while the old names start with numbers, so they're first at the list,
making it hard to understand that e.g. "51obsd" is the lua version.
None of these names are actually used at the mpv code. The C code
checks the version using the lua headers (LUA_VERSION_NUM).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lua version names which are autodetected/chosen (such as "51deb")
are used for two things:
- as key for storing the pkg-config compile/link flags.
- as ID for config.h and elsewhere - they're sanitized to use "_".
Due to some inconsistensies, if the sanitized ID is different than
the original name, then the compile/link flags are stored with the
original name as key, while the retrieval happens with the sanitized
ID - and therefore fails to find the correct flags.
The solution is to use the original name only for display purpose at
the output of configure, while using the sanitized version for
everything else, so that storage and retrieval use the same key.
Currently there's no issue and the patch has no effect, because the
sanitizer considers all the current names as valid IDs.
However, the next commit will add names which the sanitizer modifies,
such as "lua-5.1", so this commit makes such names work too.
|
| |
|
|
|
|
|
|
|
| |
This brings enabled features on the same level as disabled and
auto-detected features by having both alternatives available.
Looking at the commit message of 652895abdce4bc1ff2f00c7f21c0d0d722680806
this seems to have been the intent from the start, but this specific
definition was missing from the option creation in Features.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this drops support for swift <4.1 and with this support for xcode <=9.2.
this was the last setup that is officially working on macOS 10.12.
our old legacy build macOS 10.12 + xcode 9.2 is replaced by macOS 10.13
+ xcode 9.4.1 with swift 4.1. the macOS 10.13 + xcode 10.1 VM is
replaced by the latest macOS 10.14 + xcode 11.3.1 VM. this is the oldest
version officially supported by Apple.
this is in preparations for the following commit.
|
| |
|
|
|
|
|
| |
The existing "51obsd" is identical, and can be used to explicitly select
Lua 5.1 on Arch if necessary.
This reverts commit 36e569b242a2825b861f8f4bcef9f2ce520bc6d3.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Trigraphs such as "??=" (which are enabled by default with -std=c11)
can mess up strings, so avoid them entirely by escaping question marks.
This also drops Python 2 compatibility from file2string, making the
change to the waf rule necessary. The input file is now opened in
binary mode which is also more correct versus the old text mode
which just happened to work even on binary files.
|
| |
|
|
|
|
|
|
|
|
|
| |
remove the hardcoded swift target version and move the version
restriction to configure. this was a bad idea anyway and could lead to
mismatched object files between obj-c and swift. fix travis 10.12 legacy
build.
also update the SDK version parser to handle the new macOS 11 scheme.
Fixes #8281
|
| |
|
|
| |
Fixes #7855.
|
| |
|
|
|
| |
when building with rpi EGL is provided by librcmegl library and libEGL
should not be linked then
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
glibc/gcc make certain math functions set errno by default. This is not
required by the standard, and makes everything complexer and slower
(well done glibc). It typically prevents inlining certain math functions
too, where the compiler can turn a function call to a single
instruction, such as observed with lrint().
So this has possibly some minor performance advantages, and no
disadvantages.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously: 5.1 > 5.2 > luajit
Now: 5.2 > luajit > 5.1
I randomly decided that this should be done, since I suspect most
environments will prefer the highest Lua version anyway. There is not
much of a point picking the older one by default.
Maybe 5.1 should be dropped fully, but considering we need to stay
compatible with luajit, there is no particular incentive for this.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This warning seems to be designed well. It doesn't seem to warn on
fallthrough-only case statements, so it's compatible to well written
code.
stream_dvdnav.c had an obscure bug in inactive code, fix it.
stream_dvb.c is the only place where it intentionally falls through, I
guess I'll just leave it alone.
|
| |
|
|
|
|
|
|
| |
The previous hack for fixing #7201 requires this, but it wasn't checked.
It's easy to check, so do it. (Yes, we could just have required OpenGL
3.2 headers and skipped the earlier fix.)
For #7201.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The completion function itself now parses --list-options on the first
tab press and caches the results. This does mean a slight delay on that
first tab press, but it will only do this if the argument being
completed looks like an option (i.e. starts with "-"), so there is never
a delay when just completing a file name. I've also put some effort into
making it reasonably fast; on my machine it's consistently under 100 ms,
more than half of which is mpv itself.
Installation of zsh completion is now done unconditionally because it's
nothing more than copying a file. If you really don't want it installed,
set zshdir to empty: `./waf configure --zshdir= ...`
Improvements in functionality compared to the old script:
* Produces the right results for mpv binaries other than the one it was
installed with (like a dev build for testing changes).
* Does not require running mpv at build time, so it won't cause
problems with cross compilation.
* Handles aliases.
* Slightly nicer handling of options that take comma-separated values
and/or sub-options: A space is now inserted at the end instead of a
comma, allowing you to immediately start typing the next argument,
but typing a comma will still remove the automatically added space,
and = and : will now do that too, so you can immediately add a
sub-option.
* More general/flexible handling of values for options that print their
possible values with --option=help. The code as is could handle quite
a few more options (*scale, demuxers, decoders, ...), but nobody
wants to maintain that list here so we'll just stick with what the
old completion script already did.
|
| |
|
|
|
| |
splitting the string by spaces isn't the best idea, so we use a proper
list instead now.
|
| |
|
|
|
|
|
| |
in xcode 11 the dynamic swift libraries were moved to a separated
versioned swift folder, which can't be used for linking and only for
distribution. additional to the std dynamic swift lib folder the system
wide folder is needed for linking too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the options were tested by compiling a test program with the
option, and support was "detected" if the compilation didn't fail.
However, both gcc and clang only issue a warning on unknown warning option,
hence it never failed and all the warn options were detected as supported.
Now the tested option is used together with -Werror, which makes it fail
if it warns that the warning option is unknown.
Fixes clang unknown option warnings -Wno-format-truncation since 4a6b56f .
|
| |
|
|
|
|
| |
Use `private-code` instead of `code` here. Also this bumps up the
required wayland-client/wayland-cursor version to 1.15 which is still
pretty old anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If this is used, the runtime expects that wmain() instead of main() is
defined. This caused me severe problems in a certain now irrelevant
case. I think it's a good idea to avoid this special case.
We can just use main() and call GetCommandLineW() instead. This function
returns a single string, so use CommandLineToArgvW() to split it, and
hope it has the same semantics. Should this ever return NULL, hope that
it leaves argc at 0.
Untested, I think.
|
| |
|
|
|
|
|
|
|
|
| |
_LARGEFILE_SOURCE and _LARGEFILE64_SOURCE are not required for 64 bit
off_t, only _FILE_OFFSET_BITS.
See somewhere on: https://wiki.musl-libc.org/faq.html
I didn't test this anywhere except 64 bit Linux. It's probably a good
idea to test on Windows and all Android versions.
|
| |
|
|
|
|
|
| |
This warns about player/audio.c:253 with gcc 8.2.0. Although this
warning could be useful to check the worst case estimation, the compiler
doesn't explain how it gets its dumb, bogus result, so this is useless.
You'd just end up trying to make the compiler happy for no reason.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
this migrates our current swift code to version 5 and 4. building is
support from 10.12.6 and xcode 9.1 onwards.
dynamic linking is the new default, since Apple removed static libs
from their new toolchains and it's the recommended way.
additionally the found macOS SDK version is printed since it's an
important information for finding possible errors now.
Fixes #6470
|
| | |
|
| | |
|
| |
|
|
|
| |
this provides an easy way to check for a specific macOS SDK version and
with that the availability of features.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this is in preparation for the upcoming swift 5 transition, where static
linking was replaced by dynamic linking the swift libraries as the
preferred way, by Apple. furthermore Apple removed the static swift libs
from their dev Tools starting with xcode 10.2/swift 5.
because of ABI incompatibility dynamic linking for swift versions prior
to 5 doesn't use the system lib path for the dynamic swift libs.
for now static linking is still the default, but that will be changed
when swift 5 support is added and swift 3 support is dropped.
Fixes #6232
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the xcode-select tool only properly works with Apple provided toolchains
but not with third party ones from swift.org. in the latter case the
swift compiler executable is found in the proper path but the swift libs
from the xcode or command line tools will be picked. this leads to a
not wanted discrepancy of the swift compiler and libs and possible
errors.
instead of relying on the xcode-select tool search for the libs relative
to the swift executable. that relative path seems to be the same for all
toolchains. if for any reasons a swift executable is not found in the
relative path, fall back to the old xcode-select method.
furthermore, both static and dynamic libs will be searched for but only
the former will be used for now. this is a preparation for the upcoming
swift 5 migration.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
#6299 reported problems with earlier 3.0.x swift versions. i tested with
3.0.2/SDK 10.12.2 and just assumed it also works with the older 3.0.x
swift and 10.12.x SDK versions. due to the unstable nature of swift
there were slight API differences that caused build problems.
since swift is bundled with the SDK we just bump the minimum swift
version.
|
| |
|
|
| |
to make it consistent with the other checks and their output messages.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this was meant to be fixed by 546f038, but with --disable-cplugins the
do_the_symbol_stuff function was never called and the handle_add_object
function was again always called before the actual linking task was
created.
to fix this we explicitly call handle_add_object only after all the
tasks the do_the_symbol_stuff function is called after too.
Fixes #6028
|
| | |
|
| |\
| |
| |
| |
| |
| | |
wm4-commits--merge-edition
This bumps libmpv version to 1.103
|
| | |
| |
| |
| |
| |
| | |
C99 still works, but in theory we're using C11 features already, such as
stdatomic.h. gcc/clang let us use it in C99 mode too, but using C11 is
at least more proper.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
when passed as a string check_cc tries to split that string, since it
assumes that several include paths can be passed to it. instead we just
use a list to make it unambiguous.
|
| | |
| |
| |
| |
| |
| | |
that way we don't need to quote or escape anything.
Fixes #6220
|
| | |
| |
| |
| | |
Fixes #6212
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This reverts commit af6126adbe61fb2b6cc780025246d33df93072e6. Apple's
OpenAL support is ridiculously out of date, revert back to just using
OpenAL Soft on macOS (fixes #4645).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before, `do_the_symbol_stuff` would implicitly come before
`handle_add_object`, which adds object files to the linking task.
With newer (2.0.x) versions of waf, the ordering seems to get more
optimized, and thus we have to declare that the function that creates
the linking task should come before the task that adds object files
to the task.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
this was caused by commit 2e7a4f7. the LAST_LINKFLAGS were not added to
the linking of libmpv and that caused a linking error. manually add the
link flags the same way it's done when linking mpv.
Fixes #5968
|
| |/
|
|
|
|
|
|
|
|
|
| |
this reverts commit a174566 since the actually reason for failing has
been found. the isysroot flag overwrites the framework and library
search paths. though we only need to overwrite the former and there is
no way to just overwrite that one. we manually add the standard library
search paths to the very end of the linking command, so it won't
interfere with the search paths extracted by waf.
Fixes #5791
|
| |
|
|
| |
Needed for the new xdg-wm tiling enums.
|
