Date: Thu, 25 Jan 2024 14:16:33 +1030 From: Shane Ambler <FreeBSD@ShaneWare.Biz> To: Luca Pizzamiglio <pizzamig@freebsd.org>, FreeBSD Ports mailing list <freebsd-ports@freebsd.org>, freebsd-ports <ports@freebsd.org> Subject: Re: Subpackage explanations Message-ID: <db3ca562-ff6c-d28d-868b-f7959d317844@ShaneWare.Biz> In-Reply-To: <CAB88xy-8hAknWJDRBjbJo2%2Bw878ZMosKcvQbpKVzwq%2BH7%2Bzuyg@mail.gmail.com> References: <CAB88xy-8hAknWJDRBjbJo2%2Bw878ZMosKcvQbpKVzwq%2BH7%2Bzuyg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24/1/24 19:58, Luca Pizzamiglio wrote:
> Hi porters!
>
> At the beginning of January, we merged the support to subpackages in the
> framework.
Sounds like some good work in the right direction.
> *Use cases we want to tackle*
> The first use case we want to get rid of is master/slave ports when slave
> ports could be built with the master port.
I don't see any mention of flavors. If I merge a slave port that builds
the python bindings into the master port, can I still build multiple
flavors for the subpackage?
Any possibility that build steps can be defined to be repeated for each
desired flavor?
do-build-flavor:
make --DPYVERS=${PY_FLAVOR}
do-build-PY38:
make --DUSE_FUTURES=yes
> *Use cases we don't want to tackle (yet)*
> Subpackages enable the adoption of micro-subpackages, a typical pattern for
> Linux distributions that split a package in smaller ones: one with docs
> (-doc), one with static libraries and headers (-dev), one with manpages
> (-man), one with examples (-examples), and so on.
To me that sounds like the easy first use case. Turn the
doc/test/example options into subpackages.
--
FreeBSD - the place to B...Software Developing
Shane Ambler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?db3ca562-ff6c-d28d-868b-f7959d317844>