I have been going through the archives from this list looking for information to not only improve my build times but to make these builds safer (there are hints dropped here and there that these large builds are bad on disks which has me worried seeing that I use the same disk+partition for both my builds and my personal data).
One of the suggestions I'm anxious to try is to use tmpfs for my /tmp. I assume this is because gcc uses the environment's TMPDIR variable to define the location to place its temporary artifacts (which on most systems turns out to be /tmp)? I can certainly see how this would be a good improvement, but sometimes my /tmp ends up with lots of non-build-related cruft which can become quite large. While I would like to get gcc to use a tmpfs for its temporary files, I don't necessarily want a whole bunch of PDFs I'm reading to be taking up valuable tmpfs space unnecessarily. Therefore I'd like to keep /tmp where it is, but somehow get gcc to use a different TMPDIR when performing a build. I can't just modify my .bashrc to define the new TMPDIR since anything that uses the TMPDIR that is run after such a change (i.e. the non-build-related cruft) will just end up in TMPDIR anyway. But in bitbake's configuration there is also a variable named TMPDIR which specifies where bitbake does all of its work (e.g. ${TOPDIR}/tmp). These two TMPDIRs could possibly collide, couldn't they? Let's say I wanted to leave /tmp where it is, but modify my environment, when building, such that gcc will use /some/other/tmp (i.e. a tmpfs) for its artifacts. It is normal to modify one's environment when invoking a command, but if I wanted to modify my environment when invoking bitbake, it'll confuse the two TMPDIRs, won't it? $ TMPDIR=/some/other/tmp bitbake world This would cause both gcc and bitbake to use /some/other/tmp, no? _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto