summaryrefslogtreecommitdiffstats
path: root/waftools/detections/compiler_swift.py
Commit message (Collapse)AuthorAgeFilesLines
* waf: remove waf as a build systemLaserEyess2023-07-231-203/+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
* *.py: cosmetic changesjnozsc2020-02-271-22/+30
|
* 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.
* 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
|
* 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