| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new `BuildTarget` abstraction to centralize the code for
supporting different ways of choosing the build target (e.g --android,
--target x86_64-linux-android , --target aarch64-linux-ohos). This
is currently handled in an adhoc fashion in different commands (
mach package, install, run) leading to a proliferation of keyword
parameters for the commands and duplicated logic.
The patch introduces a new `allow_target_configuration` decorator to
do the validation and parsing of these parameters into the appropriate
`BuildTarget` subclass, which is now stored as an instance attribute
of the CommandBase class. All the code that previously relied on
`self.cross_compile_target` has been switched to use the BuildTarget.
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
GStreamer has to process plugins each time they are added when
initializing. When those files have changed, this triggers macOS
security protections which can add many seconds to access time. This
change eliminates that problem after the first packaging of libraries by
skipping packaging if everything is up-to-date and not overwriting the
dylibs everytime.
In addition, it moves a lot of the code for packaging GStreamer
libraries on macOS into the `gstreamer` module and adds type-safety and
comments to the Python.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
|
| |
|
|
|
|
|
| |
This fixes an issue where the dylib for harfbuzz cannot be found when
running unit tests on some systems, because unit tests don't get their
rpaths adjusted during build. This is quite likely an issue with dylib
dependency management. We just need a bit more exploration of how this
is traditionally handled.
|
| |
|
|
| |
The documentation claims that this is the only environment variable that
needs to be set before build.
|
| |
|
|
|
|
|
| |
These need to be installed in order to build so we can install them via
Homebrew. Do this by simply restoring the Homebrew bootstrapping logic
we had in place previously.
Fixes #27171.
|
| |
|
|
|
| |
Now that the new version of GStreamer fixes this issue, we can remove
the workarounds for this problem as well as all of the homebrew
bootstrapping logic.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes it so that the Platform classes can now handle
installing GStreamer dependencies and properly setting up the
environment including when cross-compiling. For Windows and Linux
is now installed into `target/dependencies/gstreamer` when not installed
system-wide. In addition:
1. Creating and moving existing environment path append helpers to
`util.py`.
2. Combining the `set_run_env` and `build_dev` functions and moving
some outside code into them so that it can be shared. Now code that
used to call `set_run_env` calls `build_dev` and then
`os.environ.update(...)`.
3. Adding Python typing information in many places.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
|
|
|
This starts to split platform-specific Python code into its own module,
which should help to tidy up our mach commands and make things more
reusable.
|
