We don't have many cross recipes that use PACKAGECONFIG but gdb-cross does,
so correctly remap dependencies for that case allowing the gdb recipe to be
simplified.
(From OE-Core rev: c5bb7976f4d6e8559b4b87e4c3f39135dbb40ef8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta-oe has switched from p7zip to 7zip.
p7zip recipe does not exist anymore and p7zip is provided and rprovided
by 7zip recipe.
Use real provider instead of replaced one.
(From OE-Core rev: 5aa516bfa295d5be919459dfe45f452cdec45e81)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of the base class dependency is to say "yes, I need a C cross compiler"
and this was never meant to be gcc specific. Looking at the codebase, whilst we
code triplets into this, it does overcomplicate things as there are only ever
limited, "target", "sdk" and the class extended versions like mutlilib.
After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc.
This lets us remove the "gcc" specific element as well as removing the over
complicated triplet usage.
At the same time, change the much less widely used "g++" variant to "c++" for
similar reasons and remove the triplet from virtual/XXX-binutils too.
Backwards compatibility mappings could be left but are just going to confuse
things in future so we'll just require users to update.
This simplification, whilst disruptive for any toolchain focused layers, will
make improved toolchain selection in the future much easier.
Since we no longer have overlapping variables, some code for that can just
be removed. The class extension code does need to start remapping some variables
but not the crosssdk target recipe names.
This patch is in two pieces, this one handles the renaming with the functional
changes separate in a second for easier review even if this breaks bisection.
(From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During handle PACKAGECONFIG, DEPENDS/RDEPENDS/RRECOMMENDS is appended by
calling function appendVar according to the PACKAGECONFIG setting:
PACKAGECONFIG[f1] = "\
--with-f1, \
--without-f1, \
build-deps-for-f1, \
runtime-deps-for-f1, \
runtime-recommends-for-f1, \
packageconfig-conflicts-for-f1"
[snip of base.bbclass]
pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {}
if pkgconfigflags:
...
appendVar('DEPENDS', extradeps)
appendVar('RDEPENDS:${PN}', extrardeps)
appendVar('RRECOMMENDS:${PN}', extrarrecs)
...
[snip of base.bbclass]
After following commit in meta-oe,
[fe3ba7ac5c cryptsetup: demote udev runtime dependency to recommendation]
'udev lvm2' changed from RDEPENDS to RRECOMMENDS, but RRECOMMENDS is not
handled in this process, and causes following error:
$bitbake lib32-cryptsetup
ERROR: QA Issue: lib32-cryptsetup package lib32-cryptsetup - suspicious values 'udev lvm2' in RRECOMMENDS [multilib]
In layer openembedded-core, we do have very few recipes that have
runtime-recommends-for-f1 in PACKAGECONFIG setting, but f1 is not
enabled in PACKAGECONFIGS, so not report error when multilib is enabled.
(From OE-Core rev: 2f539a1318a80d3ad5d0d43a9ba4070465e402af)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of checking for incompatible licenses in the anonymous python
and setting '_exclude_incompatible-', (re)check all the packages in
populate_packages(). This ensures that all packages are processed, even
dynamically generated ones.
The use of the '_exclude-incompatible-' variable set in base.bbclass has
been the mechanism used for per-packages licenses since it was added as
a feature (although with different names for the variable throughout
history). However, since this misses dynamic packages, calling
oe.license.skip_incompatible_package_licenses() a second time on the
actual final package set is a better solution.
(From OE-Core rev: 1816c5a5e724a7f907c9afe4a47b6699ea081ace)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves the code that skips packages with incompatible licenses to the
library code so that it can be called in other locations
(From OE-Core rev: 86eb409e3c1b30110869ec5a0027ae2d48bbfe7f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves several of the functions in license.bbclass to be library code
New function dependencies were manually verified using bitbake-dumpsigs
to ensure that bitbake identified the same dependencies even though they
are now in library code (although the new function names mean that the
task hashes still change)
(From OE-Core rev: 0333e04e353991260c5f67a72f80f3ab9dcf526a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now S and B can't be set to WORKDIR, add to PSEUDO_IGNORE_PATHS unconditionally
and simplify the code.
(From OE-Core rev: 26cd2d56261827ad8d07e2145e95f82422accac2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change do_unpack to unpack files to a subdirectory of WORKDIR instead of WORKDIR
itself. There are several good reasons for this but it is mainly about being able
to isolate the output of the unpack task and tell the files apart from other things
which are created in workdir (logs, sysroots, temp dirs and more).
This means that when the do_unpack task reruns, we can clean UNPACKDIR and know
we have a standard point to start builds from.
It also makes code in tools like devtool and recipetool easier.
To reduce the impact to users, if a subdirectory under UNPACKDIR matches
the first subdirectory under WORKDIR of S, that directory is moved into position
inside WORKDIR. This preserves the behaviour of S = "${WORKDIR}/git",
S = "${WORKDIR}/${BPN}" and other commonly used source directory setups.
The directory is moved since sadly many autotools based projects can't cope with
symlinks in their paths.
The patch also updates reproducible and SOURCE_DATE_EPOCH handling to
match the new potential source locations. We can get rid of the horrible
list of hardcoded directories in WORKDIR to ignore from that code.
(From OE-Core rev: b84eec5c4cbf4b39d6712800dd0d2fe5337721cb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having the unpack directory hardcoded to WORKDIR makes it really hard to
make any changes to the unpack process to try and allow for cleanup for example.
As a first step toward unraveling the intertwined location usages, add a
variable, UNPACKDIR which is where the fetcher is asked to unpack fetched
sources. It defaults to the existing value of WORKDIR at this point.
(From OE-Core rev: e022d62ba917790af2121da57646271ef17c03fa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you try and fetch using mercurial-native, you see certificate errors since
it is configured to find ones in the sysroot, not the system. Add the missing
dependency so that mercurial recipes using the native tool work.
Found trying to make mirroring for old meta-oe stable branches work.
(From OE-Core rev: fc567e35b374f8b08975602609ee71e64357fb3d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Source control information being present in PV used to be a hard requirement
for bitbake to operate correctly. Now that hashes are a required part of task
stamps, this requirement no longer exists.
This means we can defer the hash pieces to PKGV and simplify PV.
Use new bitbake fetcher API to inject the source revisions directly into the hash
allowing removal of some horrible code from base.bbclass and avoiding any hardcoding
about how SRCREV may or may not be used.
Use that API to object the string to append to PKGV and append that directly.
The user visible effect of this change is that PV will no longer have revision
information in it and this will now be appended to PV through PKGV when the
packages are written. Since PV is used in STAMP and WORKDIR, users will see
small directory naming and stamp naming changes.
This will mean that sstate reuse through hash equivalence where the source
revision changes but the output does not will become possible as the sstate
naming will become less specific and no longer contain the revision.
The SRCPV variable will no longer be needed in PV and is effectively now just
a null operation. Usage can be removed over time.
(From OE-Core rev: a8e7b0f932b9ea69b3a218fca18041676c65aba0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't prefix the output of LICENSE_FLAGS_DETAILS with "For further
details, see" so that recipes can put arbitrary text in their license
details instead of being limited to a specific sentence structure.
(From OE-Core rev: d606ad5c237d0e28f09f0aa783e83846cbca8d21)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes with proprietary licenses often need to use LICENSE_FLAGS so
that the user can opt-in with consent. However, if you don't consent
then the error simply tells you the license identifier but not further
context.
Add a new variable LICENSE_FLAGS_DETAILS, which will be looked in for a
flag with the name of the licence. If found then the contents are
printed as a source of further details.
For example, a recipe with an EULA may set:
LICENSE_FLAGS = "FooBar-EULA"
LICENSE_FLAGS_DETAILS[FooBar-EULA] = "https://example.com/eula"
If Foobar-EULA isn't in LICENSE_FLAGS_ACCEPTED then the error message is
more useful:
Has a restricted license 'FooBar-EULA' which is not listed in your
LICENSE_FLAGS_ACCEPTED. For further details, see
https://example.com/eula.
(From OE-Core rev: cb5cdcaf3310e889e80861ccfaf46c1bce624ac1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous code had 2 issues:
1. make hosttools/ccache always link to host's ccache (/usr/bin/ccache)
even we have one buildtools
2. make hosttools/gcc etc, link to host's gcc event we have one
buildtools when keyword ccache in buildtools's path, eg:
/mnt/ccache/bin/buildtools
This patch is for fix above issues.
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since bitbake now supports an official method to inject python modules,
switch to it.
Anyone using OE_EXTRA_IMPORTS will need to adjust their code accordingly,
probably switching to their own module namespace.
Also switch to using BB_GLOBAL_PYMODULES to list the global modules
to import.
(From OE-Core rev: 1f56155e91da2030ee0a5e93037c62e1349ba89f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I can't see how anyone would be using this very old package function definition
since package.bbclass is always inherited in modern OE. All it seems to do
is waste CPU cycles. Drop it and it's associated EXPORT_FUNCTIONS entry.
(From OE-Core rev: 56f7aa4cc0256aff96a1d720bd1931ea9a9bac8a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
