summaryrefslogtreecommitdiffstats
path: root/waftools/detections
Commit message (Collapse)AuthorAgeFilesLines
* waf: remove waf as a build systemLaserEyess2023-07-234-326/+0
| | | | | | 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.
* build: fix macOS arm buildsder richter2020-11-221-2/+4
| | | | | | | | | | | 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
* build: add -fno-math-errnowm42020-05-091-0/+1
| | | | | | | | | | | 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.
* *.py: cosmetic changesjnozsc2020-02-272-23/+31
|
* build: add -Wimplicit-fallthroughwm42019-12-111-1/+3
| | | | | | | | | | 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.
* build: fix swift linking with upcoming xcode 11der richter2019-09-221-0/+1
| | | | | | | 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.
* build: actually detect supported warning optionsAvi Halachmi (:avih)2019-09-221-2/+2
| | | | | | | | | | | | | 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 .
* win32: remove -municode from mpv binarywm42019-09-191-2/+2
| | | | | | | | | | | | | 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.
* build: stop defining _LARGEFILE[64]_SOURCEwm42019-09-191-3/+1
| | | | | | | | | | _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.
* build: silence idiotic -Wformat-truncationwm42019-09-191-1/+2
| | | | | | | 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.
* cocoa-cb: migrate to swift 5 with swift 4 fallbackder richter2019-07-211-5/+6
| | | | | | | | | | | | | 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
* build: fix build with older command line toolsder richter2019-07-211-8/+28
|
* build: make macOS SDK path and version configurable via env varsder richter2019-07-211-3/+15
|
* build: add check for macOS SDK versionder richter2019-07-211-0/+10
| | | | | this provides an easy way to check for a specific macOS SDK version and with that the availability of features.
* build: add Swift dynamic linking supportder richter2019-07-211-2/+21
| | | | | | | | | | | | | | | 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
* build: make Swift lib and compiler paths configurable via env varsder richter2019-07-211-6/+22
|
* build: add support for Swift toolchains not provided by Appleder richter2019-07-211-12/+48
| | | | | | | | | | | | | | | | | | 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.
* build: don't check for Swift when disabledder richter2019-07-211-1/+2
|
* build: use StrictVersion for swift version comparisonAkemi2019-04-021-4/+4
|
* build: enable swift debug information when requestedRodger Combs2019-03-131-0/+3
|
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-051-1/+6
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * build: prefer C11 modewm42018-05-241-1/+6
| | | | | | | | | | | | 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.
* | build: use an argument list for the Swift build argsAkemi2018-10-281-5/+7
| | | | | | | | | | | | that way we don't need to quote or escape anything. Fixes #6220
* | build: more reliable way of getting the Swift version from a stringAkemi2018-10-221-1/+4
| | | | | | | | Fixes #6212
* | build: check for Swift version and disable dependencies if neededAkemi2018-09-301-2/+2
|/
* build: fix swift build with waf 1.8.4Akemi2018-03-111-2/+2
| | | | | | | with older waf versions a node doesn't return an absolute path but just a relative one. fix this by explicitly requesting an absolute one. Fixes #5604
* cocoa-cb: change border and borderless window stylingAkemi2018-02-281-3/+3
| | | | | | | | | | | the title bar is now within the window bounds instead of outside. same as QuickTime Player. it supports several standard styles, two dark and two light ones. additionally we have properly rounded corners now and the borderless window also has the proper window shadow. Also make the earliest supported macOS version 10.10. Fixes #4789, #3944
* build: remove shell usage from swift build scriptsAkemi2018-02-131-4/+5
| | | | | | | for convenience reasons i used strings for subprocess commands instead of command lists, which made it mandatory to use a shell. for security reasons, among others, we removed the shell usage and converted the commands to actual command lists.
* build: fix swift detection with python2Akemi2018-02-131-6/+2
| | | | | | | | | c82fed8 fixed the detection with python3 but broke it on python2. the decode function on python2 converts the str to unicode which causes problems when concatenating to str when building. instead of decoding the output we change the subprocess to operate in text mode. also use check_output instead of Popen for simplicity.
* build: fix swift detection on major swift versionsAkemi2018-02-121-2/+2
| | | | | the swift version string on major versions only has two components, major and minor, the third one is missing.
* build: fix swift detection with python3Akemi2018-02-121-1/+1
| | | | | python3 returns bytes instead of str, unlike python2. explicitly decode the output.
* build: fix configure on windowsAkemi2018-02-121-7/+8
| | | | | configure failed because of a wrong check. fix the check and also only check for swift on macOS.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-121-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* win32: add more-POSIXy versions of open() and fstat()James Ross-Gowan2017-10-251-1/+1
| | | | | | | | | | | | | | Directory-opening never worked on Windows because MSVCRT's open() doesn't open directories and its fstat() doesn't recognise directory handles. These are just MSVCRT restrictions, and the Windows API itself has no problem with opening directories as file objects, so reimplement mpv's mp_open and mp_stat to use the Windows API directly. This should fix directory playback. This also populates the st_dev and st_ino fields of struct stat, so filesystem loop checking in demux_playlist.c should now work on Windows. Fixes #4711
* build: warn against VLAwm42017-07-241-1/+2
| | | | | Although C99 supports them, they are optional in C11, and we don't like/use them anyway.
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-281-1/+1
| | | | | | | | | | | | 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.
* waftools: remove trailing newlinestepshal2016-06-081-1/+0
|
* build: silence -Wunused-resultNiklas Haas2016-06-071-1/+3
| | | | | | | | 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.
* win32: build: set subsystem versionJames Ross-Gowan2015-12-201-0/+2
| | | | | | This sets the minimum supported Windows version to Windows Vista. The subsystem version also affects some Windows API functions, including GetSystemMetrics(SM_CXPADDEDBORDER).
* w32: use DisplayConfig API to retrieve correct monitor refresh rateJames Ross-Gowan2015-11-061-1/+1
| | | | | | | | | | 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>
* win32: revert wchar_t changeswm42015-08-011-1/+0
| | | | | | | | | | | 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).
* win32: more wchar_t -> WCHAR replacementswm42015-07-301-0/+1
| | | | | | | | | | | | | 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.
* build: exclude -Wredundant-declswm42015-05-091-2/+3
| | | | | | | 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.
* win32: use a platform-specific unicode entry-pointJames Ross-Gowan2015-04-111-2/+2
| | | | | | | | | | 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.
* buid: readd -Wparentheseswm42015-03-021-1/+1
| | | | | | | | | 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.
* win32: make sure __STRICT_ANSI__ is not definedJames Ross-Gowan2015-01-161-2/+2
| | | | | | | __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.
* win32: request UTF-16 API variants, Vista+ APIs, and COM C macroswm42015-01-071-0/+5
| | | | | 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.
* build: add -Werror=format-security, add -W flags in all platformswm42014-12-171-5/+7
| | | | | | | 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.
* build: add checks for some compiler warning flagswm42014-12-141-8/+8
|
* build: add -Wno-format-zero-lengthwm42014-09-261-0/+1
| | | | | | 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.
* build: enable compiler optimization by defaultTsukasa OMOTO2014-07-201-0/+3
|
* Revert "build: avoid defining _GNU_SOURCE"wm42014-07-101-2/+1
| | | | | | This reverts commit 2e6a8f260ca169e2e1a5646eecfc322de6f77307. Too many problems for now, such as with OSX and asprintf().
* build: deal with endian messwm42014-07-101-3/+0
| | | | | | | | | | | | | | | | | | | | There is no standard mechanism for detecting endianess. Doing it at compile time in a portable way is probably hard. Doing it properly with a configure check is probably hard too. Using the endian definitions in <sys/types.h> (usually includes <endian.h>, which is not available everywhere) works under circumstances, but the previous commit broke it on OSX. Ideally all code should be endian dependent, but that is not possible due to the dependencies (such as FFmpeg, some video output APIs, some audio output APIs). Create a header osdep/endian.h, which contains various fallbacks. Note that the last fallback uses libavutil; however, it's not clear whether AV_HAVE_BIGENDIAN is a public symbol, or whether including <libavutil/bswap.h> really makes it visible. And in fact we don't want to pollute the namespace with libavutil definitions either. Thus it's only the last fallback.
* build: avoid defining _GNU_SOURCEwm42014-07-091-1/+2
| | | | | | | | | _GNU_SOURCE defines the kitchen sink, and also prefers glibc definitions where glibc and POSIX conflict. Even though POSIX is worth less than toilet paper, we still prefer the POSIX definitions. rar.c needs asprintf(), which is _GNU_SOURCE-only. So we define _GNU_SOURCE too specifically for this file.
* build: set default cdrom and dvd devices on linuxAlessandro Ghedini2014-06-301-0/+2
|
* build: add some warning cflagswm42014-05-141-1/+3
| | | | | | | | | These were in the old configure script too. Two flags are explicitly tested, because I have no idea how widespread support for them is, and testing them is just easier than trying to look them up in various gcc/clang manuals. There are people using gcc 4.2 out there, so some caution is warranted.
* build: fix OpenBSD DVD/CDROM device nameswm42014-05-121-2/+2
| | | | Closes #781.
* build: conditionally use -Wempty-bodyStefano Pigozzi2014-04-261-2/+8
| | | | | | | | | -Wempty-body is not available on all gcc versions but we were using it unconditionally. Also remove the usage from the clang case. clang still defines `__GNUC__` so it still gets all the gcc specific flags. This should fix the build on systems with older gcc versions like OpenBSD which still comes bundled with gcc 4.2 for license issues.
* Remove CPU detection and inline asm handlingwm42014-04-191-28/+0
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* build: add -Wempty-body to compiler flagswm42014-04-041-2/+2
| | | | Warns against "if(0);" but not "if(0){}" - perfect for our purposes.
*