[Buildroot] Managing circular dependencies

[Buildroot] Managing circular dependencies

[John OSullivan]

Hi,

 

I have some code which I have inherited and I am in the process of
integrating into a buildroot-2012.05 based build system. The problem is that
package (A) creates a static library, in creating this it references headers
in package (B). Package (B) has a dependency on the static library built by
package (A).

The code I have is a bit of a mess but at the moment I just need to get it
building within buildroot. I can think of a number of ugly hacks but I was
wondering what approach I should take to this in buildroot. I had thought
that the staging area in output/staging might help but I am not sure what
its intended purpose is.

In terms of the package files.

I set packageA.mk to have a dependency with PACKAGEA_DEPENDENCIES =
host-cmake packageB

And also

I set packageB.mk to have a dependency with PACKAGEB_DEPENDENCIES =
host-cmake packageA

 

As it build package (A) I see a message Package (B) dependency dropped.

I had tried a line like:

#define PACKAGEA_INSTALL_STAGING_CMDS

               $(INSTALL) -D -m 0755 $(@)/packagealib.a
$(STAGING_DIR)/usr/lib/packagealib.a

 

But this just deposits the file in output/host/usr

I had thought that if I got the necessary header files into
output/usr/include or some such location then it might be the basis of a
solution.

Is there a particular approach I need to take here?

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130816/b1d2ab4e/attachment.html>

[Buildroot] Managing circular dependencies

[Thomas De Schampheleire]

Hi John,

On Fri, Aug 16, 2013 at 3:12 PM, John OSullivan
<john.osullivan@cloudiumsystems.com> wrote:
>
> I have some code which I have inherited and I am in the process of
> integrating into a buildroot-2012.05 based build system. The problem is that
> package (A) creates a static library, in creating this it references headers
> in package (B). Package (B) has a dependency on the static library built by
> package (A).
>
> The code I have is a bit of a mess but at the moment I just need to get it
> building within buildroot. I can think of a number of ugly hacks but I was
> wondering what approach I should take to this in buildroot. I had thought
> that the staging area in output/staging might help but I am not sure what
> its intended purpose is.

The staging area is where headers and libraries of packages are
placed, so other packages can use them. This copying is done when
FOO_INSTALL_STAGING is set to YES.

>
> In terms of the package files.
>
> I set packageA.mk to have a dependency with PACKAGEA_DEPENDENCIES =
> host-cmake packageB
>
> And also
>
> I set packageB.mk to have a dependency with PACKAGEB_DEPENDENCIES =
> host-cmake packageA
>
>
>
> As it build package (A) I see a message Package (B) dependency dropped.
>
> I had tried a line like:
>
> #define PACKAGEA_INSTALL_STAGING_CMDS
>
>                $(INSTALL) ?D ?m 0755 $(@)/packagealib.a
> $(STAGING_DIR)/usr/lib/packagealib.a
>
>
>
> But this just deposits the file in output/host/usr

Can you be a bit more specific?
Note that 'output/staging' is actually a symbolic link to a path in
output/host. Maybe this confused you?

>
> I had thought that if I got the necessary header files into
> output/usr/include or some such location then it might be the basis of a
> solution.
>
> Is there a particular approach I need to take here?
>

When there is no circular dependency, and package A depends on B, then
B would set B_INSTALL_STAGING to YES, and its headers and/or libraries
would be put in output/staging.
Package A would be built after B, and the compiler/linker will
automatically find the required headers and libraries.

Due to the circular dependency you are having, this approach won't
work (needless to say, the presence of this circular dependency
indicates a problem with the code, but you are already aware of that).

Should these packages really be separate? Are they actually separate
entities, separate code bases etc.? If not really necessary, you could
solve your problems by making it one package in buildroot. Then all
header and library finding can be solved within the commands of that
package.

Here is another suggestion: from the package A build commands, you
have access to the build directory of package B and vice-versa,
through the variables A_DIR and B_DIR, which are resolved when the
configure/build/install commands are executed. You could thus
explicitly reference the include directory of package B from A through
variable B_DIR. Similarly for the library.
You still need to set the right FOO_DEPENDENCIES. Assuming that the
headers are not generated but readily available in package B, then
package A can depend on the target B-extract. B can depend on A:
B_DEPENDENCIES = A
A_DEPENDENCIES = B-extract

This way, A will have access to the headers of B, and after it's
built, B can have access to the A library.

I hope this helps you in the right direction...

Best regards,
Thomas

[Buildroot] Managing circular dependencies

[John OSullivan]

Thanks for your help Thomas, I managed to break the circular dependency and
using your suggestions have the code building now. Thanks again.

-----Original Message-----
From: patrickdepinguin@gmail.com [mailto:patrickdepinguin at gmail.com] On
Behalf Of Thomas De Schampheleire
Sent: 17 August 2013 20:57
To: John OSullivan
Cc: buildroot
Subject: Re: [Buildroot] Managing circular dependencies

Hi John,

On Fri, Aug 16, 2013 at 3:12 PM, John OSullivan
<john.osullivan@cloudiumsystems.com> wrote:
>
> I have some code which I have inherited and I am in the process of 
> integrating into a buildroot-2012.05 based build system. The problem 
> is that package (A) creates a static library, in creating this it 
> references headers in package (B). Package (B) has a dependency on the 
> static library built by package (A).
>
> The code I have is a bit of a mess but at the moment I just need to 
> get it building within buildroot. I can think of a number of ugly 
> hacks but I was wondering what approach I should take to this in 
> buildroot. I had thought that the staging area in output/staging might 
> help but I am not sure what its intended purpose is.

The staging area is where headers and libraries of packages are placed, so
other packages can use them. This copying is done when FOO_INSTALL_STAGING
is set to YES.

>
> In terms of the package files.
>
> I set packageA.mk to have a dependency with PACKAGEA_DEPENDENCIES = 
> host-cmake packageB
>
> And also
>
> I set packageB.mk to have a dependency with PACKAGEB_DEPENDENCIES = 
> host-cmake packageA
>
>
>
> As it build package (A) I see a message Package (B) dependency dropped.
>
> I had tried a line like:
>
> #define PACKAGEA_INSTALL_STAGING_CMDS
>
>                $(INSTALL) -D -m 0755 $(@)/packagealib.a 
> $(STAGING_DIR)/usr/lib/packagealib.a
>
>
>
> But this just deposits the file in output/host/usr

Can you be a bit more specific?
Note that 'output/staging' is actually a symbolic link to a path in
output/host. Maybe this confused you?

>
> I had thought that if I got the necessary header files into 
> output/usr/include or some such location then it might be the basis of 
> a solution.
>
> Is there a particular approach I need to take here?
>

When there is no circular dependency, and package A depends on B, then B
would set B_INSTALL_STAGING to YES, and its headers and/or libraries would
be put in output/staging.
Package A would be built after B, and the compiler/linker will automatically
find the required headers and libraries.

Due to the circular dependency you are having, this approach won't work
(needless to say, the presence of this circular dependency indicates a
problem with the code, but you are already aware of that).

Should these packages really be separate? Are they actually separate
entities, separate code bases etc.? If not really necessary, you could solve
your problems by making it one package in buildroot. Then all header and
library finding can be solved within the commands of that package.

Here is another suggestion: from the package A build commands, you have
access to the build directory of package B and vice-versa, through the
variables A_DIR and B_DIR, which are resolved when the
configure/build/install commands are executed. You could thus explicitly
reference the include directory of package B from A through variable B_DIR.
Similarly for the library.
You still need to set the right FOO_DEPENDENCIES. Assuming that the headers
are not generated but readily available in package B, then package A can
depend on the target B-extract. B can depend on A:
B_DEPENDENCIES = A
A_DEPENDENCIES = B-extract

This way, A will have access to the headers of B, and after it's built, B
can have access to the A library.

I hope this helps you in the right direction...

Best regards,
Thomas