[yocto] confusion about DEPENDS vs RDEPENDS

[Hans Beckérus]

Hi Paul,

On Thu, Aug 29, 2013 at 10:58 AM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> Hi Hans,
>
> On Wednesday 28 August 2013 21:22:36 Hans Beckerus wrote:
>> On 2013-08-28 6:06, Paul Eggleton wrote:
>> > On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
>> >> Hi, I am a little bit confused about how to handle these two and what
>> >> they are supposed to solve. I have so far never used RDEPENDS but only
>> >> DEPENDS.
>> >
>> > DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means
>> > a runtime dependency i.e. between packages. It is worth noting though
>> > that an explicitly stated RDEPENDS will cause bitbake to actually build
>> > the recipe providing the package named in the RDEPENDS value, just at a
>> > different time. To explain exactly what each of these do:
>> >
>> > * DEPENDS = "b" in recipe "a" will translate to a's do_configure task
>> > depending on recipe b's do_populate_sysroot task, so that anything recipe
>> > b puts into the sysroot is available for when a configures itself.
>> >
>> > * RDEPENDS_${PN} = "b" in recipe "a" will translate to a's do_build task
>> > depending on recipe b's do_package_write task, so that the package file b
>> > is available when the output for a has been completely built (of course
>> > assuming that recipe b produces a package called "b", which it will with
>> > the default value of PACKAGES). More importantly it will also ensure that
>> > package "a" is marked as depending on "b" in a manner understood by the
>> > package manager being used e.g. rpm / opkg / dpkg.
>>
>> Thanks a lot! This was definitely more than I got from the description
>> of DEPENDS and RDEPENDS in the manual.
>> But I probably just read the wrong one ;)
>
> We probably should explain things to that level, I'm fairly sure we don't at
> the moment. I'll talk to Scott to see if we can work something like the above
> into the manual.
>
Great! Your input has been really helpful.

>> > By default, if recipe "foo" changes and it is mentioned in the "someapp"
>> > recipe's DEPENDS, then someapp's do_configure and all tasks that depend
>> > upon it will be re-executed next time it is called for i.e. you
>> > explicitly build someapp or build an image that contains it or some other
>> > recipe that depends upon it. The fact that you are getting the behaviour
>> > described suggests that this is either not happening, or more likely it
>> > is not having the desired effect; e.g. if internally someapp's build
>> > system doesn't drop or invalidate all of its  build output when it is
>> > reconfigured then you will get this kind of behaviour. Setting up B (the
>> > directory in which a recipe's source code is built) separate to S (the
>> > directory in which the recipe's source code has been unpacked to) can
>> > help with this since if they are separate, our build system will know it
>> > can delete B before re-executing do_compile after do_configure and you'll
>> > never have stale build output. Being able to set this up however is
>> > highly dependent on the software being built by the individual recipe;
>> > some lend themselves to this and others don't.
>>
>> Well, I have been struggling before with packages not properly
>> supporting different build and source folders so I can definitely relate
>> to what you are saying. But, does that mean I actually *have* to do it
>> this way for build dependencies to work correctly?
>
> I wouldn't have thought so, to be honest I'm just positing one situation where
> I can see how this kind of thing might be able to happen. Either do_configure,
> do_compile etc. are not re-executing (and by default they should - *if* the
> build system has a means to know about the change you have made), or they are
> re-executing but the re-execution didn't materially change the output,
> certainly not to the point where it linked against the new library version. It
> would be pretty easy to figure out which of the two happened by looking at task
> logs - either you'd see no extra task logs or you'd see in the latest
> do_compile/do_configure log that nothing much was being done.
>
>> In my case we are talking two simple autotools enabled packages and I
>> (naively?) assumed this was not something I had to take care of myself.
>
> In the ideal case it should not be.
>
>> What strikes me is that you say ""if recipe "foo" changes"", which is
>> actually not the case here! What is changed is the actual source code only.
>> Is that what is going wrong here? If I change my "foo" recipe version, would
>> that be different than to simply fetch/unpack the "foo" package source code?
>> Is "someapp" going to become purged differently in such a  scenario?
>
> OK, so just to make sure I understand what changes you are making - are you
> changing configuration/recipes/files pointed to in SRC_URI at all, or just
> modifying the unpacked source in the recipe's work directory?
>
It is the source code in the source repo that has changed. I.e. before
the change the repo for 'foo' contained version 1.0.0 of the library.
After the change the library revision was stepped to 3.0.0 due to it
not being compatible anymore and pushed. Common libtool version
handling that is.

>> What is still somewhat unclear to me is the difference between DEPENDS
>> and RDEPENDS in a simple case as this. A simple application needing a
>> dynamic library is obviously a subject for DEPENDS but to me that also
>> sounds like a typical RDEPENDS?
>>
>> However, when I build an image and include 'someapp', will 'libfoo.so.x'
>> automatically be installed or is that what I need to tell it to do using
>> RDEPENDS?
>
> For dynamically linked libraries there is one additional aspect that I didn't
> mention - we have some code in meta/classes/package.bbclass called during
> do_package that looks at the shared libraries that all binaries in a package
> link to, and automatically adds RDEPENDS for these so that the appropriate
> libraries always get installed. The subtlety though is that this happens too
> late for the build system to be able to ensure that the corresponding build-
> time requirements of the recipe are always satisfied; thus, it is possible if
> one of the libraries is rebuilding due to some other change and its recipe is
> not in your application recipe's DEPENDS, problems can occur. Bottom line is,
> if your application needs to link to a library, the recipe that builds that
> library must be in your application recipe's DEPENDS. Because of the automatic
> RDEPENDS addition at packaging time you don't need to also add the library to
> RDEPENDS yourself though; the only time you need to add something to RDEPENDS
> is when you know that a runtime dependency exists that the build system can't
> detect - examples would be packages providing shell commands that your
> application relies upon, perl, python and other such module dependencies, etc.
>
I see. The picture is getting clearer ;)
As stated before, of course I could simply do a complete clean and get
away with it. But in this case we are dealing with several developers
and it would simplify things a lot if changes like this got populated
to everyone automagically. At least now I know how it is supposed to
work, which is a giant leap forward :)

Thanks again!
Hans

> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre