Commit Graph

24 Commits

Author SHA1 Message Date
der richter 5ae6f04d6b build: fix macOS arm builds
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
2020-11-22 13:44:16 +02:00
jnozsc 611c92ef1d *.py: cosmetic changes 2020-02-27 21:36:21 +01:00
der richter f64c0115ae build: fix swift linking with upcoming xcode 11
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.
2019-09-22 17:07:51 +03:00
der richter a8c2e29868 cocoa-cb: migrate to swift 5 with swift 4 fallback
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
2019-07-21 18:13:07 +03:00
der richter 4a8bf91d4c build: fix build with older command line tools 2019-07-21 18:13:07 +03:00
der richter 916f4146a7 build: make macOS SDK path and version configurable via env vars 2019-07-21 18:13:07 +03:00
der richter 850b303732 build: add check for macOS SDK version
this provides an easy way to check for a specific macOS SDK version and
with that the availability of features.
2019-07-21 18:13:07 +03:00
der richter 3f6d79ddb6 build: add Swift dynamic linking support
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
2019-07-21 18:13:07 +03:00
der richter 770fc52215 build: make Swift lib and compiler paths configurable via env vars 2019-07-21 18:13:07 +03:00
der richter 76858ba91c build: add support for Swift toolchains not provided by Apple
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.
2019-07-21 18:13:07 +03:00
der richter f7f5bd80bb build: don't check for Swift when disabled 2019-07-21 18:13:07 +03:00
Akemi a3e6b81305 build: use StrictVersion for swift version comparison 2019-04-02 01:43:54 +03:00
Rodger Combs ec0b5e527b build: enable swift debug information when requested 2019-03-13 19:44:34 +01:00
Akemi eab30807fe build: use an argument list for the Swift build args
that way we don't need to quote or escape anything.

Fixes #6220
2018-10-28 15:48:37 +02:00
Akemi 6fbd933108 build: more reliable way of getting the Swift version from a string
Fixes #6212
2018-10-22 01:41:09 +03:00
Akemi 50787acb27 build: check for Swift version and disable dependencies if needed 2018-09-30 16:54:03 +03:00
Akemi 12b90e744d build: fix swift build with waf 1.8.4
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
2018-03-11 22:44:26 -07:00
Akemi 938ad6ebc0 cocoa-cb: change border and borderless window styling
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
2018-02-28 00:48:44 -08:00
Akemi eb224a4a55 build: remove shell usage from swift build scripts
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.
2018-02-13 20:31:09 -08:00
Akemi d0afd37709 build: fix swift detection with python2
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.
2018-02-13 20:31:09 -08:00
Akemi 8762818dd2 build: fix swift detection on major swift versions
the swift version string on major versions only has two components,
major and minor, the third one is missing.
2018-02-12 08:29:22 -08:00
Akemi c82fed85b9 build: fix swift detection with python3
python3 returns bytes instead of str, unlike python2. explicitly decode
the output.
2018-02-12 08:29:22 -08:00
Akemi 3f73520897 build: fix configure on windows
configure failed because of a wrong check. fix the check and also only
check for swift on macOS.
2018-02-12 08:29:22 -08:00
Akemi c5e4538bc4 cocoa-cb: initial implementation via opengl-cb API
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
2018-02-12 04:49:15 -08:00