summaryrefslogtreecommitdiffstats
path: root/meta/conf/bitbake.conf
Commit message (Collapse)AuthorAgeFilesLines
...
* bitbake.conf: use http:// for GNU_MIRROR instead of ftp://Koen Kooi2015-03-161-1/+1
| | | | | | | | | | | | | | | | | | | The past few weeks ftp://ftp.gnu.org has been intermittently giving errors like this: WARNING: Failed to fetch URL ftp://ftp.gnu.org/gnu/emacs/emacs-23.4.tar.gz;name=tarball, attempting MIRRORS if available ERROR: Fetcher failure: Fetch command failed with exit code 4, output: Cannot parse PASV response. accept: Connection timed out Cannot parse PASV response. Error in server response, closing control connection. Which is annoying because binutils lives there. Using http://ftp.gnu.org hasn't given any problems so far. (From OE-Core rev: 25fe8d95298a457e828190412d7148470edc5592) Signed-off-by: Koen Kooi <koen.kooi@linaro.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Add two variables for layer indexChong Lu2015-02-211-0/+6
| | | | | | | | | | | | Add BBLAYERS_LAYERINDEX_URL variable that bitbake-layers can use to find layer index. Add BBLAYERS_FETCH_DIR variable that bitbake-layers can use to specify fetch directory. [YOCTO #5348] (From OE-Core rev: ae585a7d2744222606aeb533815d22ade8e10097) Signed-off-by: Chong Lu <Chong.Lu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"Ross Burton2015-02-081-1/+1
| | | | | | | | | | | | | | | It turns out that changing WARN_QA and ERROR_QA results in do_configure's QA postfunc re-executing, so changing a QA test results in a complete rebuild. This is just too much and the lesser evil of needing to do a full rebuild to verify changed QA flags is preferable to an enforced full rebuild. This reverts commit daecfc3438122b5d146a59a5053e57006d55ccc4. (From OE-Core rev: 4c5895da16de6f00148a0755b421f07223083d09) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: don't remove WARN_QA and ERROR_QA from hashesRoss Burton2015-02-031-1/+1
| | | | | | | | | | | | | | Changing WARN_QA and ERROR_QA should cause do_package_qa to re-execute, so removing them from the sstate hashes is harmful. They were added back when sanity testing was part of packaging and this was the lesser evil, compared to changing sanity tests causing a re-package of everything. (From OE-Core rev: daecfc3438122b5d146a59a5053e57006d55ccc4) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: add PKGDATA_DIR to BB_HASHBASE_WHITELISTTing Liu2015-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | In meta/conf/bitbake.conf, PKGDATA_DIR is default to: PKGDATA_DIR = "${STAGING_DIR_HOST}/pkgdata" But in meta/conf/multilib.conf, PKGDATA_DIR is set as: PKGDATA_DIR = "${STAGING_DIR}/${MACHINE}/pkgdata" When multilib enabled, linux-libc-headers cache will be machine specific: $ bitbake-diffsigs sstate-cache/1a/sstate:linux-libc-headers:ppce6500-poky-linux:3.17.7:r0:ppce6500:3:1a0c3934d91479fd7242a5b1d407d155_package.tgz.siginfo sstate-cache/28/sstate:linux-libc-headers:ppce6500-poky-linux:3.17.7:r0:ppce6500:3:28c918e8f9f4a4cfceb3a38b258f7501_package.tgz.siginfo basehash changed from 8d3158bbddcee612fa30badd05f47b8e to 68ac258fc6c8e489f360fde3123a5894 Variable MACHINE value changed from 'b4420qds' to 'b4860qds' (From OE-Core rev: c511f65a3ccfcbaabd2ba1d1c89be81498240a2b) Signed-off-by: Ting Liu <ting.liu@freescale.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* arch-mips.inc: Change definition of TRANSLATED_TARGET_ARCHMark Hatle2015-01-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | [YOCTO #7230] In certain system configurations TRANSLATED_TARGET_ARCH will not expand in the right order for gcc-cross-candian-mips64n32 to be generated properly. This will cause SDKs to fail to generate properly. Changing the global definition of TRANSLATED_TARGET_ARCH always expands the ABIEXTENSION, which causes the OVERRIDES to pick it up as well. This effectively defines a new class of overrides for the 'n32'. The side effect is that we need to duplicate some mips64 overrides, and redefine others that were previously 'n32' or 'mips64' exclusive to have the correct semantics. (From OE-Core rev: 4b3a2b703b20583bd107f00a297d972e9bfb514a) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: move source and build output to work-sharedBruce Ashfield2015-01-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3b3f7e785e279 [kernel: Rearrange for 1.8] began the process of moving the kernel source and build artefacts out of sstate control and into a shared location. This changed triggered some workflow issues, as well as bugs related to the kernel source containing build output, and hence being dirty and breaking kernel rebuilds. To solve these issues, and to make it clear that the kernel is not under sstate control, we move the source and build outputs to: work-shared/MACHINE/kernel-source work-shared/MACHINE/kernel-build-artifacts Where kernel-build-artifacts is the kernel build output and kernel-source is kept "pristine". The build-artifacts contain everything that is required to build external modules against the kernel source, and includes the defconfig, the kernel-abiversion, System.map files and output from "make scripts". External module builds should either pass O= on the command line, or set KBUILD_OUTPUT to point to the build-artifacts. module-base.bbclass takes care of setting KBUILD_OUTPUT, so most existing external module recipes are transparently adapted to the new source/build layout. recipes that depend on the kernel source must have a depedency on the do_shared_workdir task: do_configure[depends] += "virtual/kernel:do_shared_workdir" With this dependency added, the STAGING_KERNEL_DIR will be populated and available to the rest of the build. (From OE-Core rev: 6a1ff0e7eacef595738f2fed086986fd622ec32a) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: remove internal flags from BB_SIGNATURE_EXCLUDE_FLAGSRoss Burton2014-12-031-1/+1
| | | | | | | | | | | As the code that uses BB_SIGNATURE_EXCLUDE_FLAGS uses d.getVarFlags() so doesn't get to see the internal flags, remove _append and _prepend. Also defaultval is now _defaultval and thus internal, so remove that too. (From OE-Core rev: b53e06c8fc4a8183a2f8232c13931a39b1ca0e23) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: pseudo fall back to last-resort passwd filesPeter A. Bigot2014-11-251-1/+1
| | | | | | | | | | | | | | Recipe packaging for the target requires permissions that are consistent with meta/files/fs-perms.txt which specifies certain user and group names. In the early parts of a target build base-passwd is not yet available to provide the target /etc files used for user/group lookup. Allow pseudo to fall-back to the last-resort files it installs if the target ones aren't there yet. (From OE-Core rev: 071d364b7a758ba5e546bb18c5816ac4c2e6747c) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* native.bbclass: use BUILD_* variablesRoss Burton2014-10-241-1/+1
| | | | | | | | | | | | | | Instead of replicating the logic for the host compiler naming from bitbake.conf, use the BUILD_* variables directly. Also change BUILD_CPP to use gcc -E (which native.bbclass previously used), as some recipes (e.g. grub-efi) use ${CPP} with multiple input files, which gcc -E can handle but cpp can't. (From OE-Core rev: 9237d18964ff0bf76f5c37fca21ab3974d81d0d2) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: use ??= for IMAGE_ROOTFS_SIZEChen Qi2014-09-101-1/+1
| | | | | | | | | | | | | | | | Previously, when building core-image-minimal, the rootfs size would default to 64M because we use '?=' in bitbake.conf and also '?=' in core-image-minimal.bb. The thing is, we'd like to have a default value for all images set in bitbake.conf but still allow each image recipe to set its own default value which could be overridden by users in local.conf. (From OE-Core rev: 18f499df6bcbf79d7bd0a99c4c8693268683485f) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Use 2.6.32 for oldest supported kernelKhem Raj2014-09-011-1/+1
| | | | | | | | | glibc 2.20+ wont support any older than that (From OE-Core rev: 32b3a9ca554d9ff8f3b9c2ff62cc66ee865c61bf) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Drop unused MKTEMP* variablesRichard Purdie2014-08-251-3/+0
| | | | | | (From OE-Core rev: 2bfe071d141117ddf41eade5404a0d27c349bbe8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf/debian.bbclass: Move AUTO_LIBNAME_PKGS definition to class fileRichard Purdie2014-08-231-3/+0
| | | | | | | | | Might as well move this default to the class which uses it allowing for easier reading/understanding of the class. (From OE-Core rev: 177aec177306e68bcd822dee6b29a7efbd558a91) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Set PACKAGE_ARCH with ??=Richard Purdie2014-08-231-1/+1
| | | | | | | | | | | | | | Currently its near impossible for other classes to sanely override this value with their own default. By setting a weak default we can allow other classes to change the default and allow end recipes to again override this. As far as I can tell, there shouldn't be any regressions from this change. (From OE-Core rev: 12b2a73d336d66596939eae5c9947d4054c0316e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: add bash-native to ASSUME_PROVIDEDRobert Yang2014-08-231-1/+2
| | | | | | | | | | A few native scipts requires bash-native, and we don't build bash-native, so add it to ASSUME_PROVIDED. (From OE-Core rev: 283a418a838ef285988a5ffc3888501ca7de63f1) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* insane: add checking to standardize how .bbappend files do FILESEXTRAPATHSHongxu Jia2014-07-251-0/+2
| | | | | | | | | | | | | | | | | | | When adding patches or config files from bbappend files, it requires the use of FILESEXTRAPATHS, which has been an issue and failure point for people starting to work with bitbake and oe-core. We add checking to standardize how to use FILESEXTRAPATHS. Only the format of: FILESEXTRAPATHS_append := ":${THISDIR}/Your_Files_Path" or FILESEXTRAPATHS_prepend := "${THISDIR}/Your_Files_Path:" is acceptable. [YOCTO #5412] (From OE-Core rev: 69e083237e632f7d84a7b218dd12d1a5ad95a229) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: move BB_NUMBER_THREADS and PARALLEL_MAKE to bitbake.confRoxana Ciobanu2014-07-231-0/+6
| | | | | | | | | | | | | Currently, BB_NUMBER_THREADS and PARALLEL_MAKE default to unset and are set in local.conf. Now that we have the automatic probing, the default values can be set in bitbake.conf and an example of explicitly defining how many tasks to run can be moved to local.conf.sample.extended. [YOCTO #6217] Signed-off-by: Roxana Ciobanu <roxana.ciobanu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lib/oe/image.py: check the rootfs size against IMAGE_ROOTFS_MAXSIZERobert Yang2014-07-101-0/+4
| | | | | | | | | | | | | * Check the rootfs size against IMAGE_ROOTFS_MAXSIZE (if set) * Add comments for IMAGE_ROOTFS_SIZE to not confuse with IMAGE_ROOTFS_MAXSIZE [YOCTO #2610] (From OE-Core rev: 6acd4fc8d5e642b5c6c75fcc40dd8f37caf7ddcf) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: automatically add libexecdir/BPN/.debug to -dbgRoss Burton2014-07-031-1/+1
| | | | | | | | | | | | pkglibexecdir is a fairly common location for package-specific binaries (in automake this is $libexecdir/$PACKAGE), and binaries in there are already installed to FILES_PN, so add the corresponding .debug directory to FILES_PN-dbg. (From OE-Core rev: 4d3ffde4649ed116a1c21afef41f71bfe1d471de) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* native.bbclass: Properly define directoriesMatthieu Crapet2014-06-141-1/+2
| | | | | | | | | | | | | | | | | | For most users this commit will have no effect. But if you come across the idea of giving different names for paths, you'll get some troubles. When a recipe inherit native, properly define bindir, sbindir, includedir, sysconfdir, datadir (using xxxdir_native definitions from meta/conf/bitbake.conf). For example, edit "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/quilt-native/temp/log.do_configure" and see what are the arguments given by oe_runconf. Notice that ${docdir}, ${mandir}, ${infodir}, ${localstatedir} have no associated _native definition. (From OE-Core rev: 15345ddd4be6a0b041b3d6caaad48d46b22142e9) Signed-off-by: Matthieu Crapet <Matthieu.Crapet@ingenico.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf/qemu: Move QEMU_OPTIONS to qemu.bbclassRichard Purdie2014-06-141-13/+0
| | | | | | | | | | The QEMU_OPTIONS variables belong in qemu.bbclass so move them there. The only users of them inherit qemu.bbclass. There is no point in pushing these into every recipe. (From OE-Core rev: 5824293de37919e89f60192836997281933e23d6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Add QEMU_OPTION for ppc7400 as used by qemuppcRichard Purdie2014-06-141-0/+1
| | | | | | | | | | | Currently, qemuppc prints warnings about gdk-pixbuf postinstalls not working due to illegal instructions. This is due to qemu running with the wrong cpu type. Add an option for ppc7400 so that qemuppc works correctly. (From OE-Core rev: 5995fdbe81799f1ecf5de722cb2eb95ccb2aa860) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* texinfo.bbclass: native/cross uses dummy texinfo; target uses host's Texinfo.Max Eliaser2014-06-131-0/+1
| | | | | | | | | | | | | | | To unpack that to more than a single line: -native and -cross recipes are made to use the dummy Texinfo utilities provided by texinfo-dummy-native if they invoke those utilities at build time. The target-architecture (cross-compiled) recipes still use the genuine Texinfo utilites. Right now, they still use the host system's Texinfo utilities, but could be made to use the texinfo-native recipe we already ship with some config file changes. (From OE-Core rev: 160087f754eabf5da90fb51997e19d2e585aac4a) Signed-off-by: Max Eliaser <max.eliaser@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Set a dafault value for TUNE_PKGARCHRichard Purdie2014-06-011-0/+1
| | | | | | | | | | | | | | | If we don't do this, we see an exception: ERROR: Failure expanding variable MACHINE_ARCH, expression was ${@[d.getVar('TUNE_PKGARCH', True), d.getVar('MACHINE', True)][bool(d.getVar('MACHINE', True))].replace('-', '_')} which triggered exception AttributeError: 'NoneType' object has no attribute 'replace' Setting a default value avoids this error and allows the sanity checker to trigger instead. (From OE-Core rev: 106e9a3f594658b6a207f1f29bd4007616cc31d6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: add default ${CPAN_MIRROR}Tim Orling2014-05-271-0/+1
| | | | | | | | | | * Set default to http://search.cpan.org/CPAN/, as it should be (From OE-Core rev: 7cf349c3f1f195d529fbd73ce4bf63a439ffa4e6) Signed-off-by: Tim Orling <TicoTimo@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* mirrors.bbclass: Add mirror site for savannahChanghyeok Bae2014-05-111-0/+2
| | | | | | | | | | | | | | | | * The SRC_URI is not accessible. So need to add mirror site referred by the original site. * The problem is that http://download.savannah.gnu.org/releases redirects to closest mirror and few mirrors (e.g. .jp) weren't working correctly while http://download-mirror.savannah.gnu.org/releases/ seems to be reliable. * Add SAVANNAH_GNU_MIRROR and SAVANNAH_NONGNU_MIRROR variable in bitbake.conf. * Change the SRC_URI using the new variable. (From OE-Core rev: af00b6544f60e4d7581f9d9767f9d3f574392359) Signed-off-by: Changhyeok Bae <changhyeok.bae@lge.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipesRichard Purdie2014-04-301-1/+1
| | | | | | | | | This allows them to co-exist together in the native sysroot, with one set of cross tools per target architecture. (From OE-Core rev: a2c5509520d5c3e082f55844e6545d0309565f8f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Adds bitbake qemu option for ppc e6500 & ppc e6500-64b.Valentin Cobelea2014-03-271-0/+2
| | | | | | | | | | This patch adds the bitbake qemu option for the ppc e6500 & ppc e6500-64b architectures. (From OE-Core rev: 62b0f09c13aa8e9c75ddea286586d1a2385a80be) Signed-off-by: Valentin Cobelea <valentin.cobelea@enea.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta/conf/bitbake.conf: add STAMPCLEAN to BB_HASHBASE_WHITELISTRobert Yang2014-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | The problem is that do_configure.sigdata depends on STAMPS_DIR because: do_configure -> STAMPCLEAN -> STAMPS_DIR this will make the sigdata generated by "STAMPS_DIR=/tmp/stps bitbake -S recipe" doesn't match the ones in our build dir, but it should. We can add STAMPS_DIR or STAMPCLEAN to BB_HASHBASE_WHITELIST to fix the problem, but we can't add STAMPS_DIR since once it is in BB_HASHBASE_WHITELIST, the "STAMPS_DIR=/tmp/stps bitbake -S recipe" would not run again. [YOCTO $6031] (From OE-Core rev: faf3e74d5c488a66fdabd485eb916f555d7353fd) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: add new vardepvalueexclude varflag to BB_SIGNATURE_EXCLUDE_FLAGSPaul Eggleton2014-03-071-2/+2
| | | | | | | | | | | | | We don't want the value of this varflag itself entering any signatures, ever. Part of the fix for [YOCTO #5897]. (From OE-Core rev: 1497d3d4b10844aa19ce6dcceed25aa36454160f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Drop -fpermissiveRichard Purdie2014-03-051-2/+2
| | | | | | | | | | | | Drop the -fpermissive C++ compiler flag. We've had this around for years, most code should have been fixed long ago. Its possible some recipes may fail however we can (and should) just use the flag where needed. An OE-Core world build seems to work just fine with this change. (From OE-Core rev: 24dd8e129447013ee98609f3892ec414b1b21340) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: add BBINCLUDED and BB_INVALIDCONF to config hash whitelistPaul Eggleton2014-02-171-1/+1
| | | | | | | | | | These variables should not influence the config hash, i.e. changing them shouldn't trigger a reparse of the metadata, so whitelist them. (From OE-Core rev: 8feb51267647d0760f5bec3a8b6f95f4481d9b0d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* conf/bitbake.conf: default HOMEPAGE to blank instead of unknownPaul Eggleton2014-02-111-1/+1
| | | | | | | | | | | | | | | | The default value for HOMEPAGE of "unknown" has been in place since the early OE-Classic days, but it doesn't really make sense - "unknown" is not a valid URL and it just means we have to explicitly check for this hardcoded string if we're displaying the value in some form of UI, such as Toaster. This has required some changes to the packaging classes as they previously did not expect the value to be blank. (From OE-Core rev: 244e1d73ef58e92d73c098044c66bd784644b933) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: add full stop to default DESCRIPTIONPaul Eggleton2014-01-021-1/+1
| | | | | | | | | | | | | SUMMARY should not end with a full stop; however if DESCRIPTION is not set in a recipe and thus defaulted from SUMMARY, the additional DESCRIPTION values for other standard packages e.g. ${PN}-dev look a bit odd without a full stop separating the SUMMARY value and the rest of the text. Add a full stop to avoid this. (From OE-Core rev: 4b022399815f32166c402d458a40afa6470fc776) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: set a default for MACHINE_FEATURESPaul Eggleton2014-01-021-0/+1
| | | | | | | | | | | | | | Ensure that if MACHINE_FEATURES is not set by the machine config that we don't end up with expansion errors during parsing. Technically since the introduction of MACHINE_FEATURES_BACKFILL = "rtc" this is unlikely to be a problem unless "rtc" is also added to MACHINE_FEATURES_BACKFILL_CONSIDERED, however we should be consistent with DISTRO_FEATURES which is defaulted in bitbake.conf. (From OE-Core rev: bf2c8946d96524aaa91ab43762c963ea38ccc342) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Exclude WORKDIR changes from sstate checksumsRichard Purdie2013-12-201-1/+1
| | | | | | | | | | | | | | | The layout of stamp files ensures that changes to WORKDIR mean recipes get rebuilt correctly. Since WORKDIR usually contains MULTIMACH_TARGET_SYS and that depends on tune variables, including WORKDIR in sstate checksums adds a lot of noise to the system for what amounts to no gain. On the other hand, removing it reduces noise, reduces the size of the siginfo files and reduces the amount of processing bitbake has to do. It therefore seems like dropping it from the checksums is an all around win. (From OE-Core rev: 453353e05d027c6a505d1e13a7982718a13bca8b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf/native.bbclass: Use FC instead of F77 for fortranRichard Purdie2013-12-051-2/+2
| | | | | | | | | | | | | gcc tooling appears to be standardising around the FC variable naming. This patch changes the F77 namespace to FC instead and use the default gfortran compiler. If anyone needs the F77 variables or tools, those can still be made on a case by case basis. Also updates local.conf.sample.extended accordingly. (From OE-Core rev: ae8c17be2845eff2be8394a5d9a45e6aa321c33d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Remove obsolete/unused MIRROR cruftPhil Blundell2013-11-201-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | ADOBE_MIRROR, HANDHELDS_CVS and E_SVN were broken links and not used by any recipe in oe-core. FREEDESKTOP_CVS is no longer useful because all the source code that matters is in git; no recipe in oe-core still uses the CVS repository. E_MIRROR, FREEBSD_MIRROR, FREESMARTPHONE_GIT still point to valid-seeming locations but there are no recipes in oe-core that use them. Any layers which need these variables can define them for themselves. GPE_SVN, GPE_EXTRA_SVN, GPEPHONE_MIRROR and GPEPHONE_SVN are not used by any recipe in oe-core and the corresponding projects seem to be mostly dead upstream. Again, any layers which still wish to use these variables can define them locally. All the above are just wasting space in bitbake's datastore and would be better deleted. (From OE-Core rev: 3b333896c71689c664475d53daed52404bf6b21b) Signed-off-by: Phil Blundell <philb@gnu.org> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: remove CPU_FEATURES defaultsPaul Eggleton2013-11-141-3/+0
| | | | | | | | | | This variable has been unused since the tune file overhaul two years ago. (From OE-Core rev: a1d9f2374ede768057fd364da6c0e1eeeb10499f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: remove BOOTSTRAP_EXTRA_* variable defaultsPaul Eggleton2013-11-141-7/+0
| | | | | | | | | | These were for task-bootstrap in OE-Classic and have never been used in OE-Core. (From OE-Core rev: f4692afb518f07e17fbd35a2023877b7041abef9) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Default DISTRO to nodistroRichard Purdie2013-11-121-0/+4
| | | | | | | | | | | | | | | | | An empty distro value leads to OVERRIDES and FILESOVERRIDES containing "::" entries which causes odd issues such as files being included when they shouldn't be. We could put in anonymous python to guard against empty entries but its messy and setting a default value for DISTRO to something harmless is much easier. This patch adds a weak default and ensures the sanity test doesn't complain about it. DISTRO_VERSION and SDK_VERSION are also updated to match. (From OE-Core rev: b7279f99639774674da806d37d252f388f33055f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: add WARN_QA and ERROR_QA to the hash whitelistRoss Burton2013-10-161-1/+2
| | | | | | | | | | I discovered bitbake rebuilding packages because WARN_QA had changed. These variables don't influence the output, so add them to the whitelist. (From OE-Core rev: 96204ae6e1b19783d6a3f8c590890714eaa9e2d9) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Remove double slash from PATH_prepend and PKG_CONFIG_DIRMartin Jansa2013-10-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * we correctly have ${STAGING_DIR_NATIVE}${base_sbindir_native} and then double slash in ${STAGING_DIR_NATIVE}/${base_bindir_native} * similar in PKG_CONFIG_DIR where libdir also starts with slash ${STAGING_DIR_HOST}/${libdir}/pkgconfig * also fix double slash in insane.bbclass and staging.bbclass * I was a bit nervous about staging change (in case the / was important in some weird use-case, but the extra slash is there since following commit where other extra slashes were removed only the one before libdir was kept: commit 6ea78d648951e5bbe9669412c0863daaf7f49ca5 Author: Richard Purdie <rpurdie@linux.intel.com> Date: Mon Nov 2 17:10:51 2009 +0000 autotools.bbclass: Separate out useful staging functions into base.bbclass and call from autotools classes * this isn't fixing any real-world issue AFAIK, I was just trying to debug one weird case where debugedit fails with canonicalization unexpectedly shrank by one character and it's easier to grep for '//' without many harmless instances already in run* scripts etc (From OE-Core rev: 0ddaf52e9e344986ae2b016cc068d9eee71b4347) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: define WORKDIR in terms of BASE_WORKDIRRoss Burton2013-09-221-1/+2
| | | | | | | | | | To make it easier to move WORKDIR, define it using the new variable BASE_WORKDIR, which is the root of the work directory. (From OE-Core rev: 1eee097f2e29b9d6934711c0b1d32e59e9542f53) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific ↵Richard Purdie2013-09-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | directory Currently we have a hierarchy of pkgdata directories and the code has to put together a search path and look through each in turn until it finds the data it needs. This has lead to a number of hardcoded paths and file globing which is unpredictable and undesirable. Worse, certain tricks that should be easy like a GL specific package architecture become problematic with the curretn search paths. With the modern sstate code, we can do better and construct a single pkgdata directory for each machine in just the same way as we do for the sysroot. This is already tried and well tested. With such a single directory, all the code that iterated through multiple pkgdata directories and simply be removed and give a significant simplification of the code. Even existing build directories adapt to the change well since the package contents doesn't change, just the location they're installed to and the stamp for them. The only complication is the we need a different shlibs directory for each multilib. These are only used by package.bbclass and the simple fix is to add MLPREFIX to the shlib directory name. This means the multilib packages will repackage and the sstate checksum will change but an existing build directory will adapt to the changes safely. It is close to release however I believe the benefits this patch give us are worth consideration for inclusion and give us more options for dealing with problems like the GL one. It also sets the ground work well for shlibs improvements in 1.6. (From OE-Core rev: 1b8e4abd2d9c0901d38d89d0f944fe1ffd019379) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: include machine name in DEPLOY_DIR_IMAGEPaul Eggleton2013-09-141-1/+1
| | | | | | | | | | | | | | | | | | | This allows a clean seperation between image outputs from different machines, and makes it possible to have convenience symlinks to make the output ready to deploy. This did require some surgery in runqemu; if explicit paths to the image and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined from bitbake or set in the environment. However the script does try to avoid requiring it unless it really is needed. Corresponding changes were made in the automated testing code as well. Based on an RFC patch by Koen Kooi <koen@dominion.thruhere.net> (From OE-Core rev: 7e90261aec61f79680b5eaeaf5b18c7b795412a4) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Stop providing ${P} and ${PF} by defaultRichard Purdie2013-09-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This looks nice at first glance however it turns out to be a bit problematic. Taking make as an example where there are two versions, 3.81 and 3.82, what should "bitbake make-3.81" do? Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is that a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it building 3.82 though? Its due to finding a dependency on "make-dev" and then trying to figure out what provides it? The answer is "make" and the default version of "make" is 3.82. So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". Doing so resolved the above problem since now "make" resolves to "make-3.81". So what about if we have Recipe A: DEPENDS = "make-3.81" and Recipe B: DEPENDS = "make-3.82" That is clearly an error, easy. So finally what about if we have Recipe A: DEPENDS = "make-3.81" and Recipe B: DEPENDS = "make" The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that version on everything else. Is that desired? Probably not in most cases, at least not silently. As mitigation, we could print a WARNING about this happening. The final part of the problem is that we can ony figure this out within bitbake itself. That means we'd have to teach bitbake about the PN-PV format of PROVIDES which is breaking the separation between bitbake and the metadata. We can't win :(. Nobody that I know of is using or relying on this functionality so perhaps we should just remove it instead which is what this patch does. Opinions? (From OE-Core rev: a87c205bb6cefd5e1a41b8e7ef02b5bfa380e3b6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Add SDKPKGSUFFIX to hash whitelistRichard Purdie2013-09-041-1/+1
| | | | | | | | | | The gcc recipes reference this however we account for it in the work directory paths and we don't want recipes depending on the value changing. This avoids unecessary rebuilds when switching SDKs. (From OE-Core rev: 6cdcc543ce8f532a4f66246114241b43821a111e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Drop darwin8/darwin9 usageRichard Purdie2013-08-231-4/+0
| | | | | | | | | | | There were darwin8/darwin9 overrides spinkled in the code from times gone by. Lets settle on the darwin override and remove the others since its pointless duplication. We always inject darwin into OVERRIDES if needed in the darwin8/9 cases. (From OE-Core rev: 8d5e6eed7802a6056f9eaa50a85e3eee00fe2742) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-19 07:58:14 +0000