When using CC=clang CXX=clang++, there is a binutils version check
that does not work correctly in common.gypi. Since we are stuck with
a very old version of chromium/src/build, there is nothing to do but
patch it to remove the check. Thankfully, this version number does
not control anything critical in the build settings as far as we can
tell.
Change-Id: Id749d97c5898917592f66136538ee0fa5ca78767
We never produced static release executables on Linux before, but the dynamic libraries they depended on were universal enough that nobody noticed. Now that we have released v2.5 and switched to GitHub Actions for CI builds, the Linux executables depend on libatomic, which is causing issues for some users.
Although we can't create fully-static executables on macOS or Windows, we can at least do so on Linux.
This adds a GYP variable static_link_binaries which can be set to request full-static binaries on Linux. This also exposes the Chromium build variable disable_fatal_linker_warnings, which is necessary when static linking on Linux due to static-link-related warnings generated by libcurl for its use of getaddrinfo. Finally, this enforces the definition of __UCLIBC__ with static linking on Linux, which is the only way to disable malloc hooks in Chromium base. Those hooks cause linker failures when linking statically on Linux.
A new check has been added to the release workflow to ensure that the builds we create are statically linked on Linux.
Closes#965
There is not a good reason to use a long-lived token attached to
shaka-bot. Instead, use a short-lived, automatic token generated by
GitHub Actions for the workflow run.
This converts all time parameters to signed, finishing a cleanup that
was started in 2018 in b4256bf0. This changes the type of:
- timestamps
- PTS specifically
- timestamp offsets
- timescales
- durations
This excludes:
- MP4 box definitions
- DTS specifically
This is meant to address signed/unsigned conversion issues on arm64
that caused some test cases to fail.
Change-Id: Ic752a20cbc6e31fea6bc0894d1771833171e7cbe
This fixes the Debug build of libpng on arm64 by avoiding CPU-specific
optimizations that are not in our sources list. The Release build
appears to have been unaffected, possibly due to link-time
optimizations or dead code stripping.
Change-Id: I900e00fe30b9f3748f2587cfea89a636b3a19811
This brings our default build config more in line with what is
necessary for some platforms anyway: using the system-installed
toolchain and sysroot to build everything.
We will no longer fetch source or binaries for any specific build
tools, such as libc++, clang, gold, binutils, or valgrind.
The main part of this change is the changing of default gyp settings
in gyp_packager.py. For this, a bug in gyp_packager.py had to be
fixed, in which similar GYP_DEFINE key names (such as clang and
host_clang) would conflict, causing some defaults not to be installed
properly.
In order to enable clang=0 by default, some changes had to be made in
common.gypi:
- compiler macros added to fix a compatibility issue between
Chromium's base/mac/ folder and the actual OSX SDK
- replaced clang_warning_flags variables with standard cflags
settings, plus xcode_settings for OSX
- turned off warnings-as-errors for non-shaka code, rather than
allow-listing specific warning types, since we can't actually fix
those warnings on any platform
- disabled two specific warnings in shaka code, both of which are
caused by headers from our non-shaka dependencies
Also, one warning (missing "override" keyword) has been fixed in
vod_media_info_dump_muxer_listener.h.
Although these changes were done to make building simpler on a wider
array of platforms (arm64, for example), it seems to make the build a
bit faster, too. For me, at least, on my main Linux workstation:
- "gclient sync" now runs 20-30% faster
- "ninja -C out/Release" now runs 5-13% faster
The following environment variables are no longer required:
- DEPOT_TOOLS_WIN_TOOLCHAIN
- MACOSX_DEPLOYMENT_TARGET
Documentation, Dockerfiles, and GitHub Actions workflows have been
updated to reflect this.
The following GYP_DEFINES are no longer required for anyone:
- clang=0
- host_clang=0
- clang_xcode=1
- use_allocator=none
- use_experimental_allocator_shim=0
Documentation, Dockerfiles, and GitHub Actions workflows have been
updated to reflect this.
The following repos are no longer dependencies in gclient:
- binutils
- clang
- gold
- libc++
- libc++abi
- valgrind
The following gclient hooks have been removed:
- clang
- mac_toolchain
- sysroot
Change-Id: Ie94ccbeec722ab73c291cb7df897d20761a09a70
Internal CI systems and the new GitHub CI system were out of sync,
with the external system not doing any linting. Further, the internal
system was using an internal-only linter for Python.
This creates a script for Python linting based on the open-source
pylint tool, checks in the Google Style Guide's pylintrc file, creates
a custom action for linting and adds it to the existing workflows,
fixes pre-existing linter errors in Python scripts, and updates pylint
overrides.
b/190743862
Change-Id: Iff1f5d4690b32479af777ded0834c31c2161bd10
Instead of printing a binary object, treat the output of clang-format
as a utf-8 string.
b/190743862
Change-Id: I596d223792597f8157fdee2d75773131cc858c9a
Testing CI workflows is a pain. This usually involves forking the
main repo and testing various operations there, where the results will
not break the main repo.
However, some things like NPM and Docker package names were initially
hard-coded. This meant that a fork would need to customize those in
the workflows to avoid pushing official-looking packages during CI
testing.
This change moves those hard-coded names to GitHub Secrets. Though
the names are not actually secret, the secret store is per-repo, and
will be independent in a fork. This makes it easier to avoid
accidentally pushing official-looking releases during testing, even if
the fork has access to the same auth tokens.
Change-Id: Ide8f7aa92a028dd217200fca60881333bf8ae579
It turns out that workflows were the wrong way to abstract reusable
pieces of work. This turns common steps into custom actions (build
docs, build packager, test packager) which can be used as encapsulated
steps in multiple workflows.
This is a much more natural way to avoid duplication compared to the
previous approach of triggering one workflow from another. This also
has the benefit of all of the steps of a release being represented on
GitHub as a single workflow, making it easier to understand what is
happening and what event triggered those steps.
Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
- Document necessary repo secrets
- Compress build artifacts directly to the arifacts folder
- Log test commands as they are executed
- Add comments
Change-Id: I1cc150995d339e2e93bee4570d80263dae362bb9
This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with
GitHub Actions. In addition to using GitHub Actions to test PRs, this
also expands the automation of releases so that the only manual steps
are:
1. Create a new CHANGELOG.md entry
2. Create a release tag
Workflows have been create for building and testing PRs and releases,
for publishing releases to GitHub, NPM, and Docker Hub, and for
updating documentation on GitHub Pages.
When a new PR is created, GitHub Actions will:
- Build and test on all combinations of OS, release type, and library
type
Appveyor's workflow took ~2 hours, whereas the new GitHub Actions
workflow takes ~30 minutes.
When a new release tag is created, GitHub Actions will:
- Create a draft release on GitHub
- Extract release notes from CHANGELOG.md & attach them to the
draft release
- Build and test on all combinations of OS, release type, and library
type, aborting if any build or test fails
- Attach release artifacts to the draft release, aborting if any
one artifact can't be prepared
- Fully publish the draft release on GitHub
- Publish the same release to NPM (triggered by GitHub release)
- Publish the same release to Docker Hub (triggered by GitHub release)
- Update the docs on GitHub pages
Closes#336 (GitHub Actions workflow to replace Travis and Appveyor)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
In e2efb5d4, I fixed shared_library builds on Windows, but I
introduced another issue in which the libpackager_type variable was
not correctly defined by default. This meant that the build only
worked with this variable explicitly-defined in GYP_DEFINES when
gclient sync was run.
This fixes the default definition so that libpackager_type does not
need to be defined explicity.
Related to #318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: If353e1d3c312ab0c568d4d4d2b789e922d7216e1
Shared library builds worked, but failed tests because they were made
with the wrong CRT linker settings. Strings allocated within the
library could not be freed outside the library because the dynamic CRT
was not used.
This sets necessary gyp variables to link with a dynamic CRT on
Windows, thereby fixing tests running in shared library mode that
otherwise hung in a GitHub Actions environment.
Related to #318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: Iffefd27c2aa4ec479ce1d10b099483e417d2231f
To make shared_library builds work on Windows with MSVS 2019, this
commit:
- Silences a useless warning about a private member in dll-exported
Status class.
- Exports the File class used by packager.exe
- Removes the explicit File dependency in packager.exe in favor of
libpackager, now that File is exported
- Add missing defines in packager.exe and packager_test.exe that
instruct the linker to import Status and File from the library
Closes#318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: I091f1655d88d36f353f7df497101eef17729eefe
At this point static_library builds are working in MSVS 2019. shared_library builds are still not working.
Closes#867 (MSVS 2019)
Issue #318 (progress toward shared_library support on Windows)
Issue #336 (progress toward replacing Travis & Appveyor with GitHub Actions, which uses MSVS 2019)
b/190743862 (internal; tracking replacement of Travis)
We do not use clang to build on Windows, so we should skip trying to
update clang. This is critical to MSVS 2019 support, since the older
clang tools we depend on do not recognize that newer environment.
Since we don't need clang anyway, skipping the update avoids useless
errors about finding a matching clang version for the environment.
Issue #867 (MSVS 2019)
Issue #336 (progress toward replacing Travis & Appveyor with GitHub
Actions, which uses MSVS 2019)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: I5600ed809b11e68444034a06cc891403e6bfb5cc
Because a StreamState object contains a unique_ptr, it is not
copyable. A vector of StreamStates, therefore, causes a compile error
on resize or push_back, both of which invoke the copy constructor.
I don't know why MSVS complains, but clang does not.
To fix this, I'm changing vector<StreamState> into deque<StreamState>.
At this point static_library builds are working in MSVS 2019.
shared_library builds are still not working.
Issue #867 (MSVS 2019)
Issue #336 (progress toward replacing Travis & Appveyor with GitHub
Actions, which uses MSVS 2019)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: Iaa9d5fc357102d15eac96c29ebeee7c7236e976b
e7079f0e0e..caa60026e2
In order to use MSVS 2019, gyp must be upgraded. The old version
didn't recognize MSVS 2019, but the newer version does.
This isn't everything that's needed, but it's a first step.
Created with:
roll-dep src/packager/tools/gyp
Issue #867 (MSVS 2019 support)
Issue #336 (progress toward replacing Travis & Appveyor with GitHub
Actions, which uses MSVS 2019)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: I26c433682b1bfd584bf3af0bb4e0bd04646535c1
It is not working correctly in gcc 4.8 or earlier, which is still
popular (bundled by default in CentOS 7).
Issue #865, #929.
Change-Id: I136446a70831bd0237cd29646dd349fe7558176b
Legacy players, e.g. older versions of ExoPlayer, do not handle default webvtt text alignment correctly. Need to specify `align:center` explicitly cues without text alignment for backwards compatibility.
Fixes#925.
- Do not write the HTTP PUT response to cache which can potentially overflow the cache buffer as it is not consumed.
- VLOG(1) instead of LOG(ERROR) on HttpFile::Size() as it can be called during normal code execution.
- Add a command line flag `--user_agent` to allow users to specify their custom user agent string.
Fixes#939.
It is not working correctly in gcc 4.8 or earlier, which is still
popular (e.g. bundled by default in CentOS 7).
Fixes#865, #929.
Change-Id: I55a42428dbd2a12fc2c3b1e6a49fdd662a295dca
For windows running `GYP_DEFINES='target_arch=X64'` shows an error GYP_DEFINES is
not recognized as an internal or external command.
The actual command is to set the value of GYP_DEFINES. so it should be
`SET GYP_DEFINES='target_arch=X64'`.
Joey Parrish
Joey Parrish
nvincen
Daniel Cantarín
KongQun Yang
sr90
Samidh
Mattias Wadman
Vishal Shah
Jacob Trimble
Suraj kumar (sk)
Sergio Garcia Murillo