On 2021-01-17, Nicolas Boulenguez wrote:
>> > diff --git a/debian/control b/debian/control
>> > index 6f4cc17906..ff3e528e50 100644
>> > --- a/debian/control
>> > +++ b/debian/control
>> > @@ -47,7 +47,9 @@ Description: A boot loader for embedded systems
>> > intended to be easy to port and to debug, and runs on many
>> > supported architectures, including PPC, ARM, MIPS, x86, m68k,
>> > NIOS, and Microblaze.
>> > - ${uboot:platforms}
>> > + .
>> > + Included platforms:
>> > + ${u-boot:platforms}
>>
>> These changes are unrelated to restructuring the package. Please drop
>> them for now and/or submit separatelty. I've considered changes like
>
> Package-specific substitution variable names are motivated by the
> overall change because they allow gencontrol to be executed only
> once. The only other way I can imagine to show each executed action is
> one more ugly Make loop calling dh_gencontrol on each package, with an
> ugly Make test on notools…But your change to the above only adds static text "Included platforms:" to several packages. It could be applied as is without any of the other changes in this already huge patch, so would be best to keep separate from the other changes. It is a bit of a distraction and not worth getting too deep into that rabbit hole... >> > # Select the subarchs for DEB_HOST_ARCH >> > all_subarchs := $(shell dh_listpackages --arch --no-package=u-boot-tools) >> > -# DEB_BUILD_PROFILES=pkg.uboot.subarch.SUBARCH may >> > -# limit builds to only certain subarchitectures >> > -# e.g. pkg.uboot.subarch.rockchip will only build rockchip targets. >> > -ifeq (,$(filter pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES))) >> > - built_subarchs := $(all_subarchs) >> > -else >> > - built_subarchs := $(patsubst pkg.uboot.subarch.%,u-boot-%,$(filter >> > pkg.uboot.subarch.%,$(DEB_BUILD_PROFILES))) >> > -endif >> > +# This variable is intended for command line override: >> > +built_subarchs := $(all_subarchs) >> > >> > %: >> > # The -N options prevents a lots of warnings about obviously missing >> > files. > >> How is this to be used with, say, sbuild? > > I am not using sbuild, so I fail to guess the implicit part of your > question. With sbuild, currently I can: sbuild --profiles=pkg.uboot.subarch.MATCH Which will only build the targets that match MATCH. It admittedly is a small abuse of build profiles. I use it to quickly test target-specific changes, without having to build all the unrelated targets, while still getting the benefits of building in a clean chroot with only the appropriate build-dependencies installed. > If the problem is to pass options to debian/rules, this seems possible > with something like: > # sbuild '--debbuildopt=--rules-file=debian/rules built_subarchs=S' > Similar options could be documented for > dpkg-buildpackage/pbuilder/whatever. Not familiar with passing arguments to debian/rules this way, but if it works, I've learned something. :) > If the problem is that sbuild requires all .debs listed in > debian/control built even empty, it is trivial to remove -N. I have > only added it in order to silent some debhelper warnings. > > Build profiles are intended for parametrization of debian/control. > For debian/rules, command line options are far more flexible. > As far as I know, a proper solution would require either an horrible > debian/control: > Package: u-boot-amlogic > Build-Profiles: <!pkg.uboot.subarch.rockchip !pkg.uboot.subarch.sunxi ..> > Package: u-boot-rockchip > Build-Profiles: <!pkg.uboot.subarch.amlogic !pkg.uboot.subarch.sunxi !..> > or horrible values for DEB_BUILD_PROFILES: > Package: u-boot-amlogic > Build-Profiles: <!pkg.uboot.noamlogic> > Package: u-boot-rockchip > Build-Profiles: <!pkg.uboot.norockchip> > ... > You have choosen not to implement these solutions. > My understanding is that the use cases are limited to > * local build for immediate installation on a given hardware > * test build before a commit > but no cross or bootstrap issues on buildds. > Is this right? Yes, for local use; a proper implementation would have the appropriate Build-Profiles listed in each package in debian/control as you describe above, and that is not implemented, or probably even reasonable to implement. live well, vagrant
signature.asc
Description: PGP signature
