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.
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.
* 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.
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.
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.
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.
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?).
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.
