gcc-source is the only gcc recipe meant to handle the fetch/unpack/patch
tasks, the other gcc recipes then depend on this.
This approach has been creating some confusion for tools like the archiver.
The simplest way to signal to these processes that there is no source
is to empty SRC_URI at the same time we disable the other tasks.
(From OE-Core rev: 0df9d45e0be59e55e585e6d25dedbf0fc55c490c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means you can have one gcc version for some gcc recipes
(e.g. crosssdk/nativesdk) and another gcc version for target code.
Also remove the preferred version entry from the default toolchains
list since the version issue is now handled automatically.
We also need to specifically handle gcc-source in the license handling
code since expanding ${PV} in the base class isn't possible. Since
gcc-source doesn't generate any packages directly this shouldn't be
an issue and whitelisting in this way is easiest (and matches the
rest of the toolchain handling).
(From OE-Core rev: 67db7182faf6742b0d971d61d8c5ba34f69d2e12)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst gcc doesn't have any source to fetch, it still needs a fetch task so that
a world fetch can run without errors. So instead of deleting the fetch task,
stub it.
(From OE-Core rev: 8e68ebbddc2bc41eb6cb607c51d6a80c54c4199d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current implementation of shared work for gcc is at best confusing. It relies
on the fetch/unpack/patch tasks having exactly the same stamps and if this gets
broken for some reason, its hard to figure out what the problem is. It also
leads to complex code in bitbake.
The benefits of shared work for gcc are clear but a better approach is needed. This
patch adjusts things so that a single new recipe (gcc-source) provides the
fetch/unpack/patch/preconfigure tasks, the rest of gcc simply depends on these tasks
and have no fetch/unpack/patch tasks of their own.
This means we should get the significant benefits (disk usage/performance) of the
single source tree but in a way which has less potential for problems and is
easier for people to understand. The cost is an extra recipe/some inc files
which is probably a good tradeoff.
(From OE-Core rev: ceaa0a448dc5ebddb4f7fb94fb8a503a1c0248c3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie
Ross Burton