[OE-core] [PATCH] meson.bbclass: Fix build issues with /tmp mounted with noexec

[Mark Asselstine]

On Wednesday, October 10, 2018 4:32:56 PM EDT Nirbheek Chauhan wrote:
> On Thu, Oct 11, 2018 at 1:50 AM Mark Asselstine
> 
> <mark.asselstine at windriver.com> wrote:
> > Definitely a bug in that it doesn't propogate as an error.
> 
> Note that compiler checks currently never raise an exception, and -1
> is the all-inclusive "error condition" for when the size of a variable
> could not be determined. Perhaps we should add a kwarg to sizeof()
> that forces it to error out if the size could not be determined, or if
> an unexpected error occurs.

I can only speak from my perspective as a user here, and that is a "silent" 
fail such as this is evil.

Firstly because this took some time to dig up. Understandably in this instance 
the build failure was only taking place in automated build infra which made it 
difficult to inspect logs and such to narrow in on the issue. Even if I had 
easier access to a failed build this would have taken time to uncover, btw.

Secondly and more importantly had it not been for a coding issue causing a 
build failure this would have gone unnoticed and the code built on systems 
with noexec-tmp vs not would have be completely different.

Regardless of the "-1" potentially aligning with some known default the fact 
that meson had an obvious failure attempting to run code and didn't return a 
failure return code is wrong. This is host contamination.

> 
> > On the need to
> > always use meson-private, I am 50/50 on that. Since meson respects
> > TMPDIR/TMP/ TEMP does it really need to handle this directly?
> 
> The main advantage of using tmpfs for temporary files is obvious,

Sorry, are you concerned about dirs/files being improperly cleaned up? Disk 
IO? Whenever I see "obvious" in an email I get a bit worried as I don't trust 
that what I am thinking is the same as what others might be.

> which is why we try to avoid writing that to meson-private inside the
> builddir. As I just commented on the issue, `XDG_RUNTIME_DIR` might be
> a good candidate for an exec tmpfs location.

I am not familiar with XDG_RUNTIME_DIR. On paper it does read like it could be 
used but it does seem to have a varying levels of support especially on 
systems which use sysvinit where pam is not always present.

Mark