Commit Graph

13 Commits

Author SHA1 Message Date
Khem Raj
b76c04bdcb oeqa: Build cpio with C17 std
cpio is not yet buildable with C23 standard which is default with
GCC 15, therefore ensure to apply needed bandage to keep it compiling
in C17 mode even with GCC 15

(From OE-Core rev: 0c637099887f1be421c8e1203f99631a1e040150)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2025-03-24 17:29:16 +00:00
Paul Barker
313afc99ed meta-ide-support: Mark recipe as MACHINE-specific
meta-ide-support:do_write_test_data dumps the bitbake data dictionary to
a file using export2json(). As this obviously includes the value of
MACHINE, and other MACHINE-specific variables, the recipe needs to be
marked as MACHINE-specific.

RP: Note that this patch does change the name of the environment script
since it is no longer package arch specific but machine arch specific.

[RP: Fix selftest to reference new environment file]
(From OE-Core rev: 3be2bc8a9b0c9d6a178329c8b451a6bedf255d6c)

Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-09-12 16:15:09 +01:00
Khem Raj
bd7a3fd0f7 buildcpio.py: Switch to using cpio-2.15
This helps in getting it building with newer architectures like riscv32
since it has upgraded gnulib over 2.14 which has the needed fixes.

Drop the -fno-common workaround as it is already applied to cpio

drop --disable-maintainer-mode

Fixes
configure: WARNING: unrecognized options: --disable-maintainer-mode

(From OE-Core rev: 18d303497089d3a7a893ee0eec5b0f0c78cca06d)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-02-08 10:59:06 +00:00
Khem Raj
bf7e3886ae oeqa: Use 2.14 release of cpio instead of 2.13
2.13 may not be buildable with latest compilers without patching

(From OE-Core rev: 406a33f896accc35a9cb6ab156f1e0f42dda67d8)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2023-09-26 10:25:42 +01:00
Alexander Kanavin
63e53fb8b6 build-sysroots: target or native sysroot population need to be selected explicitly
Running them in parallel is prone to races as postinsts from target sysroots
rely on executables from native sysroots which may or may not be fully prepared
yet. This was observed for example here:

https://autobuilder.yoctoproject.org/typhoon/#/builders/146/builds/468/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/147/builds/467/steps/12/logs/stdio

(From OE-Core rev: 38d7a2e45b883cf999a86af05bcc0eaa875bb47c)

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2023-09-09 12:04:55 +01:00
Richard Purdie
ce08cf4825 lib: Add copyright statements to files without one
Where there isn't a copyright statement, add one to make it explicit.
Also add license identifiers as MIT if there isn't one.

(From OE-Core rev: bb731d1f3d2a1d50ec0aed864dbca54cf795b040)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-08-12 12:00:43 +01:00
Alexander Kanavin
9b3fcb0d91 selftest/meta_ide: add a test for running SDK tests directly in a yocto build
There's been a recent discussion about how we can make the Yocto SDK
experience better [1]. One of the ideas was to eliminate the SDK
as a separate artefact altogether and simply provide everything
that the SDK and eSDKs do directly in a yocto build. This does not
mean that people have to 'learn Yocto', but rather that the integrators
should provide a well-functioning sstate cache infrastructure (same as
with minimal eSDK, really), and a few wrapper scripts for setting up the build
and the SDK environment that run layer setup and bitbake behind the scenes.

[1] https://lists.openembedded.org/g/openembedded-architecture/topic/thoughts_on_the_esdk/90990557

So without further ado, here's how you get a 'SDK' without building one:

1. Set up all the needed layers and a yocto build directory.

2. Run:
$ bitbake meta-ide-support
$ bitbake -c populate_sysroot gtk+3
(or any other target or native item that the application developer would need)
$ bitbake populate-sysroots

3. Set up the SDK environment:
. tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
(adjust accordingly)

Et voila! The Unix environment is now set up to use the cross-toolchain from
Yocto, exactly as in the SDK. And devtool/bitbake are available to extend it,
exactly as in the eSDK.

Theare are numerous benefits here: no need to produce, test, distribute and maintain
separate SDK artifacts. No two separate environments for the yocto build and the SDK.
Less code paths where things can go wrong. Less awkward, gigantic tarballs. Less
SDK update headaches: 'updating the SDK' simply means updating the yocto layers with
git fetch or layer management tooling. Built-in SDK extensibility: just run bitbake
again to add more things to the sysroot, or add layers if even more things are required.

How is this tested?

Exactly same as the regular SDK:
$ bitbake -c testsdk meta-ide-support

This runs the same toolchain tests from meta/lib/oeqa/sdk/cases as the regular
sdk testing does.

(From OE-Core rev: 5c845d7f4ea6ae7ba18ed43180dad28775cace31)

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-07-28 11:50:17 +01:00
Richard Purdie
526a956132 oeqa/selftest: Apply patch to fix cpio build with -fno-common
Patch a combined effort from Khem/RP, need to add$CONFIGURE_FLAGS
to ensure tests still work.

(From OE-Core rev: 48c82d42d510b9a8b6e819f2adf4cc1bebed8db4)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-08-26 14:33:57 +01:00
Khem Raj
504b206e37 oeqa: Use cpio 2.13 as testcase
cpio 2.12 was released in 2015 and might have used older autotools
which could result in errors like

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13779

Bumping to 2.13 will help in matching the tool versions
A good change on top would be to run

aclocal -I .; autoheader; autoconf; automake --add-missing -c

before running configure step perhaps

[YOCTO #13779]

(From OE-Core rev: 84eb1dc4fe8a11cd2d05b703070a6fb6de05b873)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-02-08 13:20:02 +00:00
Richard Purdie
db62562db5 oeqa/selftest: Markup 'machine' specific test cases
These test cases are run by the autobuilder on a machine specific basis.
Add tags to these classes so they can be controlled by the metadata rather
than hardcoded in the autobuilder config.

(From OE-Core rev: de0b761b550d591f301ee5e9c232e0d5bd1342f2)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-09-07 21:56:43 +01:00
Richard Purdie
ffae400179 meta/lib+scripts: Convert to SPDX license headers
This adds SPDX license headers in place of the wide assortment of things
currently in our script headers. We default to GPL-2.0-only except for the
oeqa code where it was clearly submitted and marked as MIT on the most part
or some scripts which had the "or later" GPL versioning.

The patch also drops other obsolete bits of file headers where they were
encoountered such as editor modelines, obsolete maintainer information or
the phrase "All rights reserved" which is now obsolete and not required in
copyright headers (in this case its actually confusing for licensing as all
rights were not reserved).

More work is needed for OE-Core but this takes care of the bulk of the scripts
and meta/lib directories.

The top level LICENSE files are tweaked to match the new structure and the
SPDX naming.

(From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-05-09 16:31:55 +01:00
Richard Purdie
c7592b0147 oeqa: Drop OETestID
These IDs refer to testopia which we're no longer using. We would now use the test
names to definitively reference tests and the IDs can be dropped, along with their
supporting code.

(From OE-Core rev: 8e2d0575e4e7036b5f60e632f377a8ab2b96ead8)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-05-09 16:31:55 +01:00
Yeoh Ee Peng
3f6eb216ef oe-selftest: meta_ide: add tests for meta-ide-support
QA team were testing meta-ide-support manually. Add automated
tests to test that bibtake meta-ide-support will create the
toolchain and environment setup script. Also test that after
using environment setup script, one can compile c program
and build cpio project.

(From OE-Core rev: db40eba68f51d02677526dfa4bc21343d9c27958)

Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-02-15 11:23:11 +00:00