| Age | Commit message (Collapse) | Author |
|---|
|
When MACHINE_SOCARCH_SUFFIX is empty a duplicated architecture will be
included in PACKAGE_ARCHS. The expected behaviour is to not include
duplicated values and raise an error in case a MACHINE_SOCARCH package
tries to be build.
Change-Id: I98d936409554e4e7725c8af6c0a0a0344ddec751
Reported-by: Lauren Post <lauren.post@freescale.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
The 'bb.parse.SkipPackage' exception was missing a 'raise' call to
proper inform the BitBake tool parsing system about the error, now the
package is properly skipped when necessary.
Change-Id: Ie736186c8e459eea55c1455547e1da8f7111e165
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
This ensures that all MACHINE_SOCARCH feeds are part of PACKAGE_EXTRA_ARCHS.
oe-core now puts packages into feed dirs dependent on the used instruction sets.
http://cgit.openembedded.org/openembedded-core/commit/?id=3e760031f91fb87c3e2f62b77a117eb41164f259
This is true also for packages in MACHINE_SOCARCH, i.e. we get in deploy/ipk for
an angstrom based build:
armv7ahf-vfp-neon-mx6qdl armv7at2hf-vfp-neon-mx6qdl
so we must put both into PACKAGE_EXTRA_ARCHS.
TUNE_FEATURES defines if arm and/or thumb feeds are possible with the
current configuration.
Change-Id: I47ed7c3a5cbdc488801cd9198e822f9845565559
Signed-off-by: Max Krummenacher <max.oss.09@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
s/PACHAGE_ARCH/PACKAGE_ARCH
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
|
|
This allow to easy reuse of binary packages among similar SoCs. The
usual use for this is to share SoC specific packages among different
boards. The class can be used to share GPU packages for i.MX53 boards
(as all them share the AMD GPU) and i.MX6 based boards (as all them
share Vivante GPU).
It inspects the database and identify if the package provides or
depends on one of subarch provided values and if it does, it sets the
PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
machine specific filter, it sets it to MACHINE_ARCH.
This reduces the amount of packages we build, for example in case of
core-image-x11 we:
$ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
75
So we reuse 75 binaries; these would be build otherwise.
It being dynamically set or statically set it has following benefits:
* correctness: it is easier to ensure the system behaves as expected
* correctness for non-tracked recipes: new recipes, if depending on
virtual/kernel or GPU has the right architecture choosen, without a
.bbappend file for them
* safeness: non-expert users get a more adequate behavior as the
complexity of choosing the right architecture is simplified for them
* easy maintenance: it is easier for me, as maintainer, to maintain a
code which decides what to do than having hundreds of bbappend files
for it
Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
Otavio Salvador
Max Krummenacher
Javier Viguera