aboutsummaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-source.inc
AgeCommit message (Collapse)Author
2015-12-14nopackages: Add class for recipes which don't generate packagesRichard Purdie
It turns out writing the same list of packaging tasks multiple times in multiple places is error prone. Move this to a new class 'nopackages", migrate existing users and add glibc-initial and libgcc-initial since we don't want packages for those recipes. This means the sstate for those recipes won't be installed, saving small amounts of build time and bandwidth. A reference to the old package_write task is also dropped. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-06-11gcc-source.inc: fix STAMPCLEAN to avoid race issueRobert Yang
Fixed race issue when build more than one gcc-source and inherit rm_work, for example: $ bitbake gcc-source-4.9.2 gcc-source-5.1.0 File "/path/to/bitbake/lib/bb/build.py", line 512, in exec_task return _exec_task(fn, task, d, quieterr) File "/path/to/bitbake/lib/bb/build.py", line 489, in _exec_task make_stamp(task, localdata) File "/path/to/bitbake/lib/bb/build.py", line 599, in make_stamp os.unlink(name) OSError: [Errno 2] No such file or directory: '/path/to/tmp/stamps/work-shared/gcc-4.9.2-r0.do_rm_work_all.02cf1ed9b79d4edb0a51d3b913b7f9ba' This is because make_stamp() uses glob.glob() to remove the old stamps before create the new one, when gcc-source-5.1.0 removes gcc-4.9.2-r0's stamp, we may get the error. We can't use deltask do_rm_work_all as do_rm_work since it is a recrdeptask, otherwise: ERROR: Command execution failed: Traceback (most recent call last): File "/path/to/bitbake/lib/bb/command.py", line 102, in runAsyncCommand commandmethod(self.cmds_async, self, options) File "/path/to/bitbake/lib/bb/command.py", line 324, in generateDotGraph command.cooker.generateDotGraphFiles(pkgs_to_build, task) File "/path/to/bitbake/lib/bb/cooker.py", line 847, in generateDotGraphFiles depgraph = self.generateTaskDepTreeData(pkgs_to_build, task) File "/path/to/bitbake/lib/bb/cooker.py", line 672, in generateTaskDepTreeData rq.rqdata.prepare() File "/path/to/bitbake/lib/bb/runqueue.py", line 587, in prepare generate_recdeps(dep) File "/path/to/bitbake/lib/bb/runqueue.py", line 575, in generate_recdeps add_resolved_dependencies([taskData.tasks_fnid[t]], tasknames, newdeps) TypeError: list indices must be integers, not NoneType Update STAMPCLEAN to contain ${PV} to fix the problem. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-05-27gcc-source.inc: set PATH for gnu-configize, not for cdAndre McCurdy
Setting OE's PATH for the 'cd' command has no real effect. In the normal case it has no effect for the gnu-configize command either (since OE's PATH is already set in the context which runs do_preconfigure) but it may be useful when manually re-running a failed gnu-configize commandline copied from an error log, etc. Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-30gcc-shared-source: Add PV to PNRichard Purdie
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 <richard.purdie@linuxfoundation.org>
2015-03-09gcc-source: fix bug to avoid building error.Bian Naimeng
gcc-source don't do do_package_write_rpm, so we should set PACKAGES = "" to avoid the building error if we want generate srpm, otherwise, we get the error as below. ERROR: Task do_deploy_archives in meta/recipes-devtools/gcc/gcc-source_4.9.bb \ depends upon non-existent task do_package_write_rpm in \ meta/recipes-devtools/gcc/gcc-source_4.9.bb Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-12-03gcc: Rework shared workRichard Purdie
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 <richard.purdie@linuxfoundation.org>