summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-source.inc
Commit message (Collapse)AuthorAgeFilesLines
* gcc-source: add comment explaining why a function is PythonRoss Burton2017-03-041-0/+2
| | | | | | | (From OE-Core rev: ead8a8e9695ea47ecf8c8eba9cd06cc1a12cc289) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc/gcc-source: Move libcc1 manipulation into gcc-sourceRichard Purdie2017-01-261-0/+5
| | | | | | | | | | | | | | Currently there is a race where if you build -cross-canadian without building gcc (target) you see QA errors about RPATHS. I've tracked this down to this manipulation where the target gcc recipe changes libcc1 in the shared sources directory. As long as you build things in the right order, the problem doesn't occur. Since its changing ${S} move it to gcc-source and avoid the race, saving RP some head scratching about why unrelated changes failed to build cleanly. (From OE-Core rev: 626064c69b6fd1b5cead6995097f99e5fbda3f19) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-source.inc: cleanly disable do_rm_workPatrick Ohly2017-01-191-1/+1
| | | | | | | | | | | | | | | | Using "deltask" assumes that do_rm_work has been added already, which won't be the case anymore in the upcoming improved rm_work.bbclass, because then an anonymous python method will add do_rm_work. Setting RM_WORK_EXCLUDE works with the current and upcoming rm_work.bbclass and is the API that is meant to be used for excluding recipes from cleaning, so use that. (From OE-Core rev: 1f2a3cdadac1560b0e03a7be25f452ad48c27ddb) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nopackages: Add class for recipes which don't generate packagesRichard Purdie2015-12-141-6/+2
| | | | | | | | | | | | | | | | 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. (From OE-Core rev: cece583d58f82a50c3a4eac876eb326ac3b8f5e5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-source.inc: fix STAMPCLEAN to avoid race issueRobert Yang2015-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. (From OE-Core rev: 9099d46a46ee511d1b7e496472c5b973e8e8feaf) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-source.inc: set PATH for gnu-configize, not for cdAndre McCurdy2015-05-291-1/+1
| | | | | | | | | | | | | | 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. (From OE-Core rev: 4321fce801daea50baaaae9ed6a141c6e7712834) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-shared-source: Add PV to PNRichard Purdie2015-04-301-0/+1
| | | | | | | | | | | | | | | | | | 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>
* gcc-source: fix bug to avoid building error.Bian Naimeng2015-03-101-0/+1
| | | | | | | | | | | | | | | | 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 (From OE-Core rev: 704fd8f1efbd7fa9368cfe4f956abf24cd58664e) Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Rework shared workRichard Purdie2014-12-031-0/+34
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>