| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Quite unlikely to be run afterwards, and the macOS runner on
Github actions seems to work.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
apparently travis changed the homebrew setup and that broke the build.
reasons was a different homebrew version that doesn't support the new
brew cli.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
homebrew is removing 10.13 support and some of the dependencies start
building rom source now. we will just pin the last working homebrew
version, similar to the 10.12 build
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
As we are now on 20.04, these packages are now available in the
repositories. Additionally, they don't need to be separately pulled
in, as gcc-mingw-w64 already does that.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
brew update tries to update the java cask, which it tries to build from
source. this takes too long and leads to a timeout of the job. we can't
manually remove the java cask because of a bug in the too old brew cask
version and the old formula. we just remove the whole cask tap and call
it a day, since we don't need it anyway.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the problem here is that with time, and because the macOS VMs don't get
updated, the homebrew update is getting longer since more and more
changes have to be pulled. to prevent that, we cache the homebrew
installation folder after the update. that way we don't have to update
several months worth of updates every build. for the legacy build we
have to check put master again to actually cache the newest homebrew
version.
additionally to that, we also do the same as on the legacy build, with
the addition of not removing all installed formulas but only the ones
we don't need. so we don't need to reinstall those.
|
| |
|
|
|
|
|
|
|
| |
just remove all pre installed formulas, since we don't need the majority
of it. after that install what we need. this also fixes the brew update
of those formulas where the source links were broken like popt.
this also helps when the build times out due to building some formulas
from source that are not dependencies we need.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
private keys should be prefixed with an underscore (_). the sudo key is
deprecated and doesn't influence anything anymore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Travis is currently having "problems" and is spamming IRC all the time
with pointless failure notifications. Make it so that it hopefully sends
a message only when it goes from success to failure, which should
exclude these cases.
While I'm at it, I'd like to complain how idiotic it is to store CI
configuration in a project's source repository. Such a repository should
only contain things that are inherently part of the code's function, not
part of the organization. You don't store bug reports, build results,
the website, developer access controls, etc. in this repository either.
But for CI it's supposed to be OK? I'm all for this "configuration as
code" thing, but what it should mean is that you store configuration
files in some git managed repository, NOT necessarily that you dump them
into the main source code repo. There are many arguments why it should
not be there, such as this very commit. I have a feeling this is mostly
just because all these idiotic web services just want to advertise their
shit and bind customers by not giving easy ways to treat source code and
CI service configuration orthogonal. And so, the source code repo gets
clobbered with stupid shit (both in the set of files and the commit
history). It's fairly idiotic and my tolerance for it is waning. (Oh, of
course you could probably jump through hoops to make it a separate repo,
but I bet that is complicated and has all kinds of downsides because it
won't be the way "it's meant to be used".)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
don't build our own ffmpeg anymore and instead use the bottled version
from homebrew. update the newest macOS image. also handle macOS 10.12
as a legacy OS since homebrew and Apple stopped supporting it.
nevertheless it's helpful to build on that version since it's the last
version we support building on. it's a bit special since we have to pin
the homebrew-core version to a previous one where all the bottles for
macOS 10.12 are still available, otherwise it would build nearly
everything from source and that would take ages. also start caching the
homebrew cache folder for downloads.
|
| |
|
|
|
| |
python3 couldn't be set up as system default because it was blocked by
the old python2.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Adds a script to clone and build FFmpeg as well as
to configure and build mpv itself. Currently only used
for macOS and contain hard-coded macOS specific options.
* Still works with the Linux containers.
* Moves our language back to "c" from "generic"
* Defines our Linux distribution as "bionic" to get the latest
Ubuntu base distribution to be the runner for our containers.
* Adds the homebrew add-on for macOS package installation for
dependencies. Installs everything required but FFmpeg, as we want
to have our own FFmpeg snapshots.
|
| |
|
|
|
| |
OBS isn’t really set up to support this. If needed, we should instead
git clone FFmpeg as part of the CI. I don’t think it is, though.
|
| | |
|
| |
|
|
|
|
|
| |
This way the docker container in itself does no networking.
It seems like travis disabled network access from the actual docker
containers.
|
| | |
|
| |
|
|
| |
Much faster build cycles and more consistent download bandwidth.
|
| |
|
|
| |
This way it doesn’t override CC.
|
| |
|
|
|
| |
Travis now builds with Clang and containers with git snapshots
of some dependencies.
|
| |
|
|
|
|
|
|
| |
Temporary solution. For now, this builds using a container image
based on openSUSE Tumbleweed with the current FFmpeg release.
More containers will be added (at least with git snapshots of FFmpeg
and libass), and Travis will eventually be replaced with something
we have more control over.
|
| |
|
|
|
|
|
|
|
| |
This includes codec/muxer/demuxer iteration (different iteration
function, registration functions deprecated), and the renaming of
AVFormatContext.filename to url (plus making it a malloced string).
Libav doesn't have the new API yet, so it will break. I hope they will
add the new APIs too.
|
| |
|
|
| |
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Libav has been broken due to the hwdec changes. This was always a
temporary situation (depended on pending patches to be merged), although
it took a bit longer. This also restores the travis config.
One code change is needed in vd_lavc.c, because it checks the AV_PIX_FMT
for videotoolbox (as opposed to the mpv format identifier), which is not
available in Libav. Add an ifdef; the affected code is for a deprecated
option anyway.
|
| |
|
|
|
| |
I sure hope they merge the patches for the required hwdec info API,
which is already in FFmpeg.
|
| | |
|
| |
|
|
| |
No idea if this is correct.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
For libav-stable, we download the Libav tarball, which is failing,
because their certificate is broken:
ERROR: cannot verify libav.org's certificate, issued by `/C=US/O=Let\'s Encrypt/CN=Let\'s Encrypt Authority X3':
Issued certificate has expired.
I don't intend to support Libav's overly old releases anymore anyway,
so if you want to use Libav, use its git master.
|
| |
|
|
|
|
|
| |
Travis being a POS again.
Why does the travis config even have tol be part of the source code
repo? This makes no sense.
|
| | |
|
| |
|
|
| |
Don't let it clutter the top level directory.
|
| |
|
|
|
| |
Moved to #mpv and #mpv-devel, respectively. Travis details were also
updated.
|
| |
|
|
| |
Let's see if it works better now.
|
| |
|
|
| |
Useless crap that keeps spamming IRC with timeout "errors".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't actually want to test all possible combinations; we just want
to make sure that each thing (e.g. linux/osx, ffmpeg/libav) is tested
once.
Exclude Linux + ffmpeg-stable, because ffmpeg-stable is already tested
on OSX.
Exclude clang on Linux, because OSX needs clang, but Coverity (running
on Linux) needs gcc - so we use gcc only on Linux.
I also wanted to reduce the matrix to a single configuration when
running Coverity, but apparently this is not possible.
(See travis-ci/travis-ci#1975.)
|
| |
|
|
|
|
|
|
| |
For the purpose of running Coverity correctly.
Although I'm not sure how well this works. gcc won't work on OSX, and
also I'm not sure if Coverity will act up if the build matrix has more
than 1 configuration (will it submit multiple scans?).
|
| |
|
|
| |
They said YAML is "simple"...
|
| |
|
|
| |
I guess it didn't like the duplicate env section.
|
| |
|
|
|
| |
Not sure if this will work. Probably not, because it seems Coverity will
be missing some required dependencies.
|
| |
|
|
|
|
|
|
| |
The travis guys were so nice to activate multi OS support for us (it's a beta
feature). So now we build on OS X ass well to check for OS X specific breakage.
Later I might investigate further and build with the minimum supported SDK
version so that we don't break older systems by using newer Cocoa features.
|
| |
|
|
|
|
|
|
| |
Libav 10 was released, so we can enable testing the stable Libav version
again.
FFmpeg 2.2 was also released, but since we still support 2.1.4, we stick
with the older version. This is better for testing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have no tolerance for this garbage anymore. There are tons of issues
with it (see e.g. previous commit), and there is no reason to use it
either. Use Libav git, or Libav 10 when it's released.
This also drops support for earlier FFmpeg release, which have exactly
the same issues as Libav 9. FFmpeg 2.1.4 is still supported, because
it's the latest release, and is reasonably recent. (Although this will
probably also be dropped as soon as FFmpeg 2.2 is released.)
Assumed version table (lots of nonsensical numbers):
FFmpeg 2.1.4 FFmpeg (n2.2-rc2) Libav (v10_beta2)
lavu 52.48.101 52.66.100 53.3.0
lavc 55.39.101 55.52.102 55.34.1
lavf 55.19.104 55.33.100 55.12.0
lsws 2.5.101 2.5.101 2.1.2
lavi 3.90.100 4.2.100 4.2.0
lswr 0.17.104 0.18.100 -
lavr 1.1.0 1.2.0 1.1.0
libpostproc and libavdevice are not interesting.
Following this commit, code needed just to support old Libav versions
will start to be removed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a new build system based on waf. configure and Makefile
are deprecated effective immediately and someday in the future they will be
removed (they are still available by running ./old-configure).
You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`.
TL;DR: we couldn't get the same level of abstraction and customization with
other build systems we tried (CMake and autotools).
For guidance on how to build the software now, take a look at README.md
and the cross compilation guide.
CREDITS:
This is a squash of ~250 commits. Some of them are not by me, so here is the
deserved attribution:
- @wm4 contributed some Windows fixes, renamed configure to old-configure
and contributed to the bootstrap script. Also, GNU/Linux testing.
- @lachs0r contributed some Windows fixes and the bootstrap script.
- @Nikoli contributed a lot of testing and discovered many bugs.
- @CrimsonVoid contributed changes to the bootstrap script.
|
| |
|
|
|
| |
Lately Travis sends out many notifications that are false positives caused by
timeout. We are annoyed.
|
| |
|
|
|
|
|
| |
We will use the 'ci' branch to do test builds of big features before they
are merged into master.
[ci skip]
|
| |
|
|
| |
[ci skip]
|
| |
|
|
|
| |
Use YAML's anchor/reference syntax to DRY up the YAML file. Also fix a bug
that caused the IRC notification to always take place (even on success).
|
|
|
Travis-CI [1] is a continous integration cloud service. It is free for
open-source projects and tigthly integrated tiwh GitHub so there is really
no reason for us not use it. :)
For now we are going to do a total of 4 builds, mainly to test ffmpeg/libav
API breakage:
* ffmpeg-stable, libass-stable
* ffmpeg-git, libass-stable
* libav-stable, libass-stable
* libav-git, libass-stable
The compiler that is currently used is clang for two reasons:
* running 8 build targets would be quite wasteful and take a long time
* clang is less tested and used during development than gcc (especially on
linux)
Currently Travis doesn't support OS X environments alongside Linux ones [2].
When it will, we will add a fifth build target to test OS X compilation
breakage.
README was moved to markdown to add the little build status image. I ran some
tests with my GitHub fork and couldn't get images to show up using ReStructured
Text.
[1]: https://github.com/travis-ci/travis-ci
[2]: travis-ci/travis-ci#216
|
