forked from JustAMan/JavascriptSubtitlesOctopus
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TheOneric] Build cleanup #43
Merged
dmitrylyzo
merged 20 commits into
jellyfin:master
from
dmitrylyzo:TheOneric/build_cleanup
Dec 26, 2022
Merged
[TheOneric] Build cleanup #43
dmitrylyzo
merged 20 commits into
jellyfin:master
from
dmitrylyzo:TheOneric/build_cleanup
Dec 26, 2022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We knowingly expose deprecated API. Cherry-picked from: libass@b2fd3e7
We are bound to one toolchain and most results of the config-time checks were ignored anyway. This is more concise and doesn't require a configuration step. Cherry-picked from: libass@25bd926
The build currently warns about building an executable with an object-file extension and recommends to use -c, -shared or -r eventhough we already use -r. I'm not sure what -r is supposed to do, but -c only compiles and not links the input which should be exactly what we want here and using -c gets rid of the warning without any apparent negative effects. Cherry-picked from: libass@3ce0643
Cherry-picked from: libass@2348874
Cherry-picked from: libass@cd33db7
Possibly it did something in older versions, in current ones only the compiler set __EMSCRIPTEN__ macro is used in checks. Cherry-picked from: libass@e240038
Cherry-picked from: libass@1ad1434
The last released version of brotli we use, blocks the install target when building with emscripten, which is why we currently need to manually copy files of interest to their installed location. This adds complexity and is prone to failure with future changes. Upstream no longer blocks installations with emscripten since google/brotli@ce222e3 from 23.06.2021. We could just bump the brotli version to latest master, but then our already existing patch would need updating and from a quick look it appears as if other things changed as well which might not all be compatible with our baseline target out of the box. AN eventual new release with release notes will hopefully detail the changes in a more accessible form. As a safe option, just backport the upstream commit as another patch. We still need to normalise the static library names though. Cherry-picked from: libass@ab214a6
Cherry-picked from: libass@b91a88e
Cherry-picked from: libass@7823300
emscripten already sets PKG_CONFIG_LIBDIR preventing non-wasm libraries installed in the system to be detected (and it doesn't provide a way for us to set _LIBDIR ourselves). Cherry-picked from: libass@e88b164
autoconf and cmake will pick up the variable from the environment. Cherry-picked from: libass@0559838
To be more concise and to keep config flags from drifting apart (they already varied slightly between submodules). Cherry-picked from: libass@85817b3
Previously some builds used a hardcoded number of 8 and others didn't set it at all falling back to a single threaded build. This still isn't ideal though. What we actually want is to fix up or Makefile to allow builders to pass the number of jobs to the toplevel and then a buildserver can distribute the available jobs across the targets allowing inter-target parallelism. For now, this already is a clear improvement. The fribidi build appears to have a borked dependency on generated sources when running from a subdir, which resulted in parallel builds sometimes failing. To fix this the relevant header is now generated explicitly before other build steps. Cherry-picked from: libass@89e899a
They appear to have been commented out since the first public release and it's not clear what they were intended for or if they'd even still work with current emscripten. Cherry-picked from: libass@4370e7b
Cherry-picked from: libass@e341e1b
The latter is required as it's picked up by buildsystems, the former is only used once by us and can easily be replaced by the latter. Cherry-picked from: libass@e2e3158
Cherry-picked from: libass@d95ddf5
It is the only project actually recognising this option. Cherry-picked from: libass@190b281
PREPARE_SRC_VPATH is supposed to prepare the source, so leave the creation of the 'configured' file to the actual Makefile target.
ae181da
to
6fb7311
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pulling from the upstream.
Original author: TheOneric
libass#139