Weird build dependency issue causing missing symbols

[Ren, Zhikui]

Maybe the problem is that this header server.hpp is generated not  a source. 
Artifact created from the same source *should* be the same (except timestamp)
If the source did not update, just a forced rebuild to create new binaries,  I can see Yocto choose not to rebuild things depend on the package.
In the case of boost, since it is devtool modified and the header is a source and not build artifact, it make sense to trigger all the rebuild. 


-----Original Message-----
From: openbmc <openbmc-bounces+zhikui.ren=intel.com at lists.ozlabs.org> On Behalf Of Bills, Jason M
Sent: Thursday, July 2, 2020 5:00 PM
To: openbmc at lists.ozlabs.org
Subject: Re: Weird build dependency issue causing missing symbols



On 7/2/2020 2:33 PM, Patrick Williams wrote:
> On Thu, Jul 02, 2020 at 12:58:43PM -0700, Bills, Jason M wrote:
>> We have narrowed this down to being caused by two separate issues:
>> 1. When phosphor-dbus-interfaces is rebuilt it will sometimes change 
>> the order of the PropertiesVariant in server.hpp.
> 
> This sounds like a bug in sdbus++.  We should be sorting the variant 
> parameters or issuing them in array order.  I'll look into it.
> 
>> 2. When the order of PropertiesVariant changes on a rebuild, the 
>> recipes that already have an old copy of server.hpp are not triggered 
>> to rebuild and are left with the old copy of server.hpp.
> 
> This isn't surprising if what is triggering the rebuild is not a Yocto 
> variable change (or git revision).  Yocto doesn't cache the contents 
> of the packages, but caches the variables that went into a build step.  
> A hash of the variables are used to look up the potential 'sstate-cache'
> files so that it can skip build steps.
> 
> If you think a variable or a git-revision should have changed with 
> what you were doing, then maybe it is something else.
> 
It seems like a header file change should trigger a rebuild, though?  If I manually edited something like a library header file, I'd expect everything that includes that library to be rebuilt with the new header change.

I tried to devtool modify boost to check the behavior, but that causes boost to rebuild every time and correctly triggers the dependent builds. 
  Maybe the case above of modifying a header file is invalid?