[bitbake-devel] is there a bitbake equivalent to "touch"ing a file for gnu make?

[Andre McCurdy]

On Tue, Feb 25, 2020 at 1:22 PM <rpjday at crashcourse.ca> wrote:
>
>    colleague emails me the following puzzler … current project based on
> wind river linux 9 (so effectively morty 2.2), so it has bitbake 1.32.
> apparently, for a specific recipe, there are intermittent build errors
> which she suspects are caused by a race condition in the build of that
> recipe.
>
>    *but* that build error only occurs when something about the underlying
> layers have changed; as in, someone checked *something* in somewhere
> forcing at least something to be rebuilt, and that error does not
> even occur on *all* rebuilds, just some of them. so the question is,
> which underlying recipe change and rebuild could be triggering this?
>
>    she *suspects* it might be openssl, as their project is making
> regular changes to openssl, and that recipe seems to be an ultimate
> dependency for quite a number of recipes, so she's just guessing
> that might be the cause.
>
>    in order to test this, she is currently running through a loop
> wherein, in order to kick off at least some recipe rebuilds, she
> makes some innocuous change to openssl, causing it to be rebuilt,
> which then rebuilds all recipes that depend on it and so on.
>
>    yuck.
>
>    on the other hand, i couldn't immediately suggest anything
> cleaner. my thought was to (somehow) fake a rebuild of openssl
> (perhaps by invalidating some timestamp), but that's not going
> to work as once it's rebuilt, it's just going to look like it
> did before, so nothing else will be rebuilt.

Not sure what you mean by "fake" a rebuild. You can force a rebuild by
e.g. manually changing something in the recipe such as PR, running
"bitbake -c cleansstate openssl", etc, but then it's a real a rebuild.
It doesn't matter if the output of the rebuild is identical to a
previous build, anything which depends on openssl will get rebuilt too
(at least for OE 2.2).

>    is there an easier way to do this? i don't have a system
> with that old a YP version at hand, so i can't test this, and
> nothing leaps to mind. is there a "make touch" equivalent
> that would drive a full rebuild of all recipes that depend
> on a given recipe, without having to actually mess with it?
>
>    i figured, "ah, this can't be that hard," but i haven't
> come up with anything.
>
> rday
>
> p.s. simply cleaning the offending recipe and rebuilding it
> won't trigger the build error (at least that's what I've been
> told) … one must change the underlying recipes at least a
> little in order to *force* a rebuild allegedly based on
> dependencies.

Right, clean doesn't remove sstate, so just running clean won't force
something to be rebuilt. You need to use cleansstate instead.

Anyway, it sounds like you just have a missing build dependency
somewhere. Making a change to openssl causes a lot of stuff to get
rebuilt (but perhaps in a different order than a full rebuild from
scratch) which is highlighting the missing dependency. Best way to
debug is to find out which recipe fails intermittently and then try
building just that recipe after running cleansstate for that recipe
and removing the entire tmp directory. It should then fail
consistently.