Age | Commit message (Collapse) | Author | Files | Lines |
|
subprocess.call() outputs to stdout, and that doesn't get
redirected to the log file, which is unnecessarily verbose.
|
|
subprocess.check_call() outputs to stdout, and that doesn't get
redirected to the log file, which is unnecessarily verbose.
|
|
This way we can run multiple of them at the same time.
Initial patch by Nirbheek Chauhan
|
|
Instead of using the global os.environ for everything. Allows
parellalising steps with different environments.
|
|
|
|
|
|
|
|
|
|
Licensing was incorrect, incomplete, and at best, ambiguous. Some
recipes were picking one license when there were many, others were
listing all the licenses and you had to pick one.
On the other hand, many projects are licensed under multiple BSD-like
licenses, and you must adhere to the terms of all of them, and there
was no way to know how from the binary packages.
Now we have an extended syntax for declaring the licensing properties
of a recipe. The licenses array can now also contain dictionaries with
License enums as keys and relative paths to files in the source tree
as values. All files specified in this way will be copied into
`share/licenses/$recipe_name`.
Common license texts which are copied verbatim by projects without
adding any specific author/copyright information have been copied into
`data/licenses/` and will be copied into `share/licenses/$recipe_name`
when a license is specified without a corresponding source tree file.
`share/licenses/$recipe_name/README-LICENSE-INFO.txt` contains
a disclaimer that this is not legal advice, and uses (AND) and (OR)
operators to declare the combinations of licenses you can pick when
adhering to the license requirements of a project.
`share/licenses/$recipe_name` is, of course, now also copied into the
devel binary packages.
I have made a best-effort to check and update the licenses in each
recipe, but I have probably missed things. Reviews and updates are
welcome. I also did not bother updating the toolchain recipe licenses
too carefully since we do not ship them with our binary packages;
except mingw-runtime.recipe (which does have an updated license).
|
|
We already do some things in post_install, but we currently only do
this for gstreamer recipes, but that's overall a bit flaky. This will
allow us to do more things in post_install and make things consistent.
|
|
freetype: You have to pick between FTL and GPLv2
frei0r-plugins: It's GPLv2+, not LGPL
openssl: Obviously, OpenSSL not BSD
harfbuzz: Actually BSD, not LGPLv2+
lame: transitioned to LGPL2, no longer GPL
nettle/gmp: licensed under all three licenses
osx-framework: No license, just copying of files from other recipes
gst-shell, vsintegration, etc: Match with gstreamer's license
toolchain: All LGPLv2+, GPLv2+, or GPLv3+
other recipes: verified by `diff -uw` on license
Remove most unused license enums, except Proprietary
|
|
On Windows builds meson recipe fails trying to
delete /scripts folder, because it is not empty.
|
|
`Scripts/` is not in PATH inside the cerbero shell, and it's also an
unexpected place for it, so just move it to `bin/` after install.
|
|
Instead, use `self.config.python_exe` which will always be a usable
Python 3 for running build commands.
|
|
Instead of doing it per-recipe, auto-detect `gtk_doc` and `examples`
options for Meson recipes and always pass `--disable-gtk-doc` for
Autotools recipes.
|
|
|
|
Log from Jenkins CI:
Cross dependency corefoundation found: NO (tried pkgconfig and framework)
sys/applemedia/meson.build:27:0: ERROR: Dependency "CoreFoundation" not found, tried pkgconfig and framework
|
|
This is needed for bzip2.recipe
|
|
The configure script supports python3, but the shebang points to python.
This increase the amount of system setup required, so simply inforce
using python3.
|
|
The old code was looking for 'rc' in the full path to the `windres`
cross-info binary path, which is obviously wrong because it will match
for instance, /path/to/sources/foo/bar/*-windres since `sources` has
`rc` in it.
Closes #93
|
|
Do the same for the build-tools recipe too. Starting with the next
release, we can start using the tarball. Need master for the latest
meson build file fixes.
|
|
It's uneeded now that cerbero/python unpacks tarballs for us. It also
conveniently solves a chicken and egg problem with an updated libtool.
|
|
|
|
|
|
These were getting pulled by recipes directly, which is incorrect and
unnecessary. Just add them to build tools instead.
|
|
|
|
GNOME, GNU, Savannah, Xiph, and SourceForge source URLs now use
templates. More templates can be added in the future. Currently, they
can be one of the following forms:
scheme://
This will download a file called %(name)s-%(version)s.tar.xz from the
canonical place on the specified server. `scheme` can be: gnome, sf,
gnu, savannah.
scheme://.tar.gz
For using the template but with the specified file extension instead
of .tar.xz
scheme://some/path/to/name-version.tar.xz
For using the template only for the mirror domain and common sources
path.
https://bugzilla.gnome.org/show_bug.cgi?id=797330
|
|
Fixes out of date glib tools throwing errors.
/usr/bin/glib-genmarshal --prefix _gdk_pixbuf_marshal --output gdk-pixbuf/gdk-pixbuf-marshal.h --pragma-once --header ../gdk-pixbuf/gdk-pixbuf-marshal.list
FAILED: gdk-pixbuf/gdk-pixbuf-marshal.h
/usr/bin/glib-genmarshal --prefix _gdk_pixbuf_marshal --output gdk-pixbuf/gdk-pixbuf-marshal.h --pragma-once --header ../gdk-pixbuf/gdk-pixbuf-marshal.list
(process:12337): GLib-Genmarshal-WARNING **: failed to open "--output": No such file or directory
(process:12337): GLib-Genmarshal-WARNING **: failed to open "gdk-pixbuf/gdk-pixbuf-marshal.h": No such file or directory
(process:12337): GLib-Genmarshal-WARNING **: failed to open "--pragma-once": No such file or directory
...
|
|
For consistency with other recipes. Also, apparently some overparanoid
firewalls block domains with 'ftp' in them thinking they're ftp URLs.
|
|
I accidentally put the same checksum for meson and ninja recipes.
|
|
This should cover all recipes; even those that aren't built by default
https://bugzilla.gnome.org/show_bug.cgi?id=797177
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1573342
|
|
|
|
|
|
|
|
Bad cherry-pick after an incorrect rebase.
|
|
Upstream PR: https://github.com/mesonbuild/meson/pull/4024
|
|
Fixes macOS detection and building, and allow glimagesink to create an
output window with gst-launch-1.0
Also remove unneeded patches from glib-tools, since that recipe is
only used for glib-mkenums, gdbus-codegen, etc.
Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
|
|
Allows cerbero bootstrap over ssh
|
|
The glib static libraries now have the correct contents, and the
pkg-config files have the correct Libs.private lines.
|
|
Also move gettext-tools earlier in the list of build tools so it's
available ASAP.
|
|
Fixes glib-networking build on Windows with MSVC.
|
|
This upstream patch fixes the linker error: 'Cannot export rpl_printf:
symbol not found' while targeting 32-bit on Windows 10.
https://bugzilla.gnome.org/show_bug.cgi?id=796825
|
|
Also add a check in Cerbero to ensure that no insecure URLs are used.
|
|
Environment variable modification in a recipe used to be done with:
self.append_env, self.prepend_env, or self.new_env
All of these were dictionaries of {string:string} mappings, which
means that if a recipe wanted to, say, append to `CFLAGS` from
multiple places within the recipe (f.ex., `glib.recipe`), you had to
carefully juggle `=` and `+=` in recipes, which was error-prone
(f.ex., `gstreamer-1.0.recipe` `variants.nodebug` was broken).
Now that we also conditionally use `self.append_env['CFLAGS']` in
`cerbero/build/build.py` for bitcode support with make-based build
systems, it's impossible to get this right in recipes. This was
causing the cross-ios-universal builds to fail on recipes that
directly set `self.append_env['CFLAGS'] = 'foo'` such as pixman.
The dictionaries have now been replaced with the following functions:
self.append_env(varname, value1, value2, ..., sep=separator)
self.prepend_env(varname, value1, value2, ..., sep=separator)
self.set_env(varname, value1, value2, ..., sep=separator)
The separator is used to join value1, value2, etc and also while
appending/prepending to the value in the env. It is optional, and
defaults to ` ` (space).
Most often the usage is very simple to translate:
self.append_env['CFLAGS'] = ' -funroll-loops '
=>
self.append_env('CFLAGS', '-funroll-loops')
If values are omitted with `self.set_env()`, the variable is unset:
self.new_env['MAKEFLAGS'] = None
=>
self.set_env('MAKEFLAGS')
An important intended feature is that multiple calls to these
functions all take effect sequentially at build time for each build
step. So, you can call append and prepend multiple times on the same
variable, and the values will be appended and prepended in that order
to the value at build time.
Note that if you call `self.set_env()` on a variable, the variable will,
of course, be set to that value and previous append/prepend
declarations will be overriden.
Reviewed-by: Jan Schmidt <jan@centricular.com>
|
|
Fixes several bugs, including a traceback with Python 3.7
|
|
Already upstream at https://github.com/mesonbuild/meson/pull/3808
Also remove an unused patch that was accidentally committed.
|
|
It hangs randomly during configure, and makes unattended builds
annoying. This is the workaround that people have been doing manually
for years on Windows.
Eventually, we will get rid of this entirely once we move to Meson.
|
|
Use --disable-fatal-warnings instead.
Also, always disable gtk-doc. No one cares about it in Cerbero.
|
|
Upstream PR: https://github.com/mesonbuild/meson/pull/3691
With this, darwin_x86_64 builds successfully for me.
|