[yocto] TMPDIR collision

[Trevor Woerner]

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?