About the external project of sdbusplus in bmcweb

About the external project of sdbusplus in bmcweb

[Lei YU]

While I was adding some new function in sdbusplus, it's found that bmcweb is
not working correctly, that it always gives errors like below.

    Jun 11 09:14:26 romulus bmcweb[1501]: terminate called after
throwing an instance of 'sdbusplus::exception::SdBusError'
    Jun 11 09:14:26 romulus bmcweb[1501]:   what():  sd_bus_process
discard: org.freedesktop.DBus.Error.AccessDenied: Operation not
permitted

Then it's noticed that bmcweb is using its own revision of sdbusplus during
build, as external project in "CMakeLists.txt.in"

It's worrying that one should expect that the whole build of OpenBMC should
use a single sdbusplus lib defined in
meta-phosphor/recipes-extended/sdbusplus/sdbusplus_git.bb, but apparently
it's not for bmcweb, and that results in the weird behavior.

When I change the "CMakeLists.txt.in" to use the same revision as the one in
sdbusplus_git.bb, the issue is gone and bmcweb behaves normally.

So the question is, why bmcweb uses sdbusplus this way? Is it possible to make
it just link against sdbusplus like other repos?

Thanks!

Re: About the external project of sdbusplus in bmcweb

[Ed Tanous]

On 6/11/19 2:29 AM, Lei YU wrote:
> While I was adding some new function in sdbusplus, it's found that bmcweb is
> not working correctly, that it always gives errors like below.
> 
>     Jun 11 09:14:26 romulus bmcweb[1501]: terminate called after
> throwing an instance of 'sdbusplus::exception::SdBusError'
>     Jun 11 09:14:26 romulus bmcweb[1501]:   what():  sd_bus_process
> discard: org.freedesktop.DBus.Error.AccessDenied: Operation not
> permitted

It should be noted, I am not seeing this behavior in my builds.

> 
> Then it's noticed that bmcweb is using its own revision of sdbusplus during
> build, as external project in "CMakeLists.txt.in"

https://github.com/openbmc/bmcweb/blob/6ca6ac12e62bd8bfbdb9a24bbfded4a138a1150a/CMakeLists.txt#L9
https://github.com/openbmc/bmcweb/blob/6ca6ac12e62bd8bfbdb9a24bbfded4a138a1150a/CMakeLists.txt#L142

Notice the YOCTO_DEPENDENCIES option.  When bmcweb is built within yocto
(which should be a majority of the time), it relies on the sdbusplus
version that yocto has decided, and ignores its own.  The
CMakeLists.txt.in is only used when building out of the yocto tree, to
enable static analysis tools to function without having to static
analyze the entire codebase.

> 
> It's worrying that one should expect that the whole build of OpenBMC should
> use a single sdbusplus lib defined in
> meta-phosphor/recipes-extended/sdbusplus/sdbusplus_git.bb, but apparently
> it's not for bmcweb, and that results in the weird behavior.

See above, my understanding is that bmcweb should be using the single
sdbusplus lib.

> 
> When I change the "CMakeLists.txt.in" to use the same revision as the one in
> sdbusplus_git.bb, the issue is gone and bmcweb behaves normally.

This is really confusing to me.  When building the openbmc image, this
should have zero effect.  Can you verify you're building with "bitbake
obmc-phosphor-image"?  What machine are you building for?

> 
> So the question is, why bmcweb uses sdbusplus this way? Is it possible to make
> it just link against sdbusplus like other repos?
> 

See above about static analysis, and building out of the yocto tree.

Re: About the external project of sdbusplus in bmcweb

[Lei YU]

On Tue, Jun 11, 2019 at 11:55 PM Ed Tanous <ed.tanous@intel.com> wrote:
>
> On 6/11/19 2:29 AM, Lei YU wrote:
> > While I was adding some new function in sdbusplus, it's found that bmcweb is
> > not working correctly, that it always gives errors like below.
> >
> >     Jun 11 09:14:26 romulus bmcweb[1501]: terminate called after
> > throwing an instance of 'sdbusplus::exception::SdBusError'
> >     Jun 11 09:14:26 romulus bmcweb[1501]:   what():  sd_bus_process
> > discard: org.freedesktop.DBus.Error.AccessDenied: Operation not
> > permitted
>
> It should be noted, I am not seeing this behavior in my builds.
>
> >
> > Then it's noticed that bmcweb is using its own revision of sdbusplus during
> > build, as external project in "CMakeLists.txt.in"
>
> https://github.com/openbmc/bmcweb/blob/6ca6ac12e62bd8bfbdb9a24bbfded4a138a1150a/CMakeLists.txt#L9
> https://github.com/openbmc/bmcweb/blob/6ca6ac12e62bd8bfbdb9a24bbfded4a138a1150a/CMakeLists.txt#L142
>
> Notice the YOCTO_DEPENDENCIES option.  When bmcweb is built within yocto
> (which should be a majority of the time), it relies on the sdbusplus
> version that yocto has decided, and ignores its own.  The
> CMakeLists.txt.in is only used when building out of the yocto tree, to
> enable static analysis tools to function without having to static
> analyze the entire codebase.

Thanks for this information, I did not notice that.

> >
> > It's worrying that one should expect that the whole build of OpenBMC should
> > use a single sdbusplus lib defined in
> > meta-phosphor/recipes-extended/sdbusplus/sdbusplus_git.bb, but apparently
> > it's not for bmcweb, and that results in the weird behavior.
>
> See above, my understanding is that bmcweb should be using the single
> sdbusplus lib.
>
> >
> > When I change the "CMakeLists.txt.in" to use the same revision as the one in
> > sdbusplus_git.bb, the issue is gone and bmcweb behaves normally.
>
> This is really confusing to me.  When building the openbmc image, this
> should have zero effect.  Can you verify you're building with "bitbake
> obmc-phosphor-image"?  What machine are you building for?

What I was doing is:

1. devtool modify bmcweb
2. Go to build/workspace/sources/bmcweb, modify the code
3. bitbake obmc-phosphor-image

So it looks like when bmcweb is being built with devtool, the
YOCTO_DEPENDENCIES is missing, is it?

Be noted that devtool is a yocto tool, see below reference:
* https://www.yoctoproject.org/software-item/devtool/
* https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe

>
> >
> > So the question is, why bmcweb uses sdbusplus this way? Is it possible to make
> > it just link against sdbusplus like other repos?
> >
>
> See above about static analysis, and building out of the yocto tree.