path: root/meta/recipes-devtools/gcc/
Commit message (Collapse)AuthorAgeFilesLines
* gcc-shared-source: Set empty SRC_URIRichard Purdie2015-09-241-0/+2
| | | | | | | | | | | 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. Signed-off-by: Richard Purdie <>
* gcc-shared-source: Add PV to PNRichard Purdie2015-04-301-2/+2
| | | | | | | | | | | | | | | | 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). Signed-off-by: Richard Purdie <>
* gcc: stub do_fetch instead of removing itRoss Burton2014-12-051-1/+4
| | | | | | | | 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. Signed-off-by: Ross Burton <>
* gcc: Rework shared workRichard Purdie2014-12-031-0/+6
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. Signed-off-by: Richard Purdie <>