Bug 7508 - Use of BR2_EXTERNAL and dependencies to existing packages
Summary: Use of BR2_EXTERNAL and dependencies to existing packages
Status: RESOLVED WONTFIX
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-04 10:37 UTC by espenfk
Modified: 2015-04-10 15:19 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description espenfk 2014-10-04 10:37:48 UTC
Hello.

I use BR2_EXTERNAL to add my own components to Buildroot. One of the components are needed for post-processing the u-boot, Linux, and rootfs images (a host tool in other words). I therefore, in the my-component.mk file pointed to indirectly by BR2_EXTERNAL, added my component to LINUX_DEPENDENCIES, UBOOT_DEPENDENCIES, and ROOTFS_POST_BUILD_SCRIPT. But my tool is not built before either. Why?

Well the answer is in the Makefile, line 378 and forward. Since the external.mk in line 392 is processed after boot, linux, and fs, values added to for instance LINUX_DEPENDENCIES in the external file have no effect on the Linux dependencies.

I come around it by adding the necessary dependencies in a package override file since this is processed in line 382, which is ok, but not optimal.

The behaviour is probably by design, but then the documentation lack some details that cost me some hours hard-core buildroot debugging.

One solution, that will not break current builds, is to add a configuration variable where one can set that the external.mk file is read before all the package, boot, linux, system , and fs files, but default it does as now.

Sp1
Comment 1 Thomas De Schampheleire 2014-10-20 19:10:17 UTC
I do not understand your use case. You say that the tool is needed for post-processing linux, uboot, etc. So why do you need to build it _before_ these targets?

It is not a good idea to try and manipulate variables of other packages from a given package. We will definitely not try to support this as it can break in many ways. 

If you add a config option for this tool, you can select it explicitly and it will be built at a right moment. Have you tried this?

If this does not work for you, please describe your use case in more detail. Thanks.
Comment 2 Thomas Petazzoni 2015-04-10 15:19:54 UTC
More details were asked about the use case approximately 6 months ago, with no feedback for Espen. Therefore, I'm closing this bug now. Please re-open with more details if needed.