[PSA] BDEPEND no longer respected when building for boards

80 views
Skip to first unread message

Mike Frysinger

unread,
Aug 2, 2022, 1:55:44 PM8/2/22
to chromium-os-dev
i've landed a change to our builds so that BDEPEND is completely ignored when building boards.  it will still be respected when building packages for the SDK itself, but when cross-compiling for boards, we'll behave as if BDEPEND is not set at all.

no action is required by developers here: continue to write ebuilds the same way you have.  do not move BDEPEND values to DEPEND like pre-BDEPEND EAPI versions worked.

if you see an error on release builders where a tool seems to be missing, it might be due to this. 
if you want a package in the SDK, you'll need to do what we've always required: add it to the virtual/sdk package.

the reason for this change is to improve board build speeds: we no longer have to process SDK depgraphs whenever building for packages.
it should also help with build reliability: we no longer (sometimes) rebuild SDK packages when building boards.  we've always relied on the SDK being updated before via the update_chroot flow.
-mike

Andrew Moylan

unread,
Aug 2, 2022, 8:51:29 PM8/2/22
to Mike Frysinger, chromium-os-dev
On Wed, Aug 3, 2022 at 3:55 AM Mike Frysinger <vap...@chromium.org> wrote:
i've landed a change to our builds so that BDEPEND is completely ignored when building boards.  it will still be respected when building packages for the SDK itself, but when cross-compiling for boards, we'll behave as if BDEPEND is not set at all.

no action is required by developers here: continue to write ebuilds the same way you have. 

A good chance to ask: What exactly should be the best practice for what to include in BDEPEND in ChromiumOS?
Is it "leave it empty for new ChromiumOS ebuilds, and add things to virtual/sdk instead, but don't remove BDEPEND from ebuilds forked from upstream"?

 
do not move BDEPEND values to DEPEND like pre-BDEPEND EAPI versions worked.

if you see an error on release builders where a tool seems to be missing, it might be due to this. 
if you want a package in the SDK, you'll need to do what we've always required: add it to the virtual/sdk package.

the reason for this change is to improve board build speeds: we no longer have to process SDK depgraphs whenever building for packages.
it should also help with build reliability: we no longer (sometimes) rebuild SDK packages when building boards.  we've always relied on the SDK being updated before via the update_chroot flow.
-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev

Mike Frysinger

unread,
Aug 2, 2022, 9:17:44 PM8/2/22
to Andrew Moylan, chromium-os-dev
On Tue, Aug 2, 2022 at 8:51 PM Andrew Moylan <amo...@chromium.org> wrote:
On Wed, Aug 3, 2022 at 3:55 AM Mike Frysinger <vap...@chromium.org> wrote:
i've landed a change to our builds so that BDEPEND is completely ignored when building boards.  it will still be respected when building packages for the SDK itself, but when cross-compiling for boards, we'll behave as if BDEPEND is not set at all.

no action is required by developers here: continue to write ebuilds the same way you have. 

A good chance to ask: What exactly should be the best practice for what to include in BDEPEND in ChromiumOS?
Is it "leave it empty for new ChromiumOS ebuilds, and add things to virtual/sdk instead, but don't remove BDEPEND from ebuilds forked from upstream"?

for packages that only build for boards, that guidance works.  for packages that build in the SDK too, listing correct BDEPEND values is important.
-mike

Tom Hughes

unread,
Sep 28, 2022, 7:51:00 PM9/28/22
to Mike Frysinger, Andrew Moylan, chromium-os-dev

Mike Frysinger

unread,
Sep 28, 2022, 11:57:11 PM9/28/22
to Tom Hughes, Andrew Moylan, chromium-os-dev

On Thu, Sep 29, 2022 at 5:34 AM Tom Hughes <tomh...@google.com> wrote:
On Tue, Aug 2, 2022 at 6:17 PM Mike Frysinger <vap...@chromium.org> wrote:
Reply all
Reply to author
Forward
0 new messages