Re: Subpackage explanations

Am 25.01.24 um 04:46 schrieb Shane Ambler:
> 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.

Building docs often has very large dependency trees, and if docs
are made subpackages, then building a port will require all these
dependencies to be available, which may take orders of magnitude
longer than building the port itself.

The same is sometimes true for tests that have large dependencies.