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