This approach is a simple rewrite of slaveport mechanism but in a fashion
where it is self hosted within a single port
It allows to easily add support to, for example py2 and py3 packages, in a very
simple way by reusing the slaveport mechanism
Differential D8840
Very simplistic and minimal initial version of flavors bapt on Dec 18 2016, 9:59 PM. Authored by Tags None Referenced Files
Details
This approach is a simple rewrite of slaveport mechanism but in a fashion It allows to easily add support to, for example py2 and py3 packages, in a very
Diff Detail
Event TimelineComment Actions Note that it works with all existing tools (portmaster/portupgrade/poudriere/synth) without any modification (as long as they do support a third level of directory for ports Comment Actions Mmmm, so, one depends on a flavored port by doing bar:foo/bar/flavor. How do I depend on a port, whatever its flavor ? Comment Actions Yes
That is not possible yet (this is the next step)
Comment Actions I've answered in the mail thread, but asking here specifically again: why not make it even simpler? FLAVOURS= sub1 sub2 OPTIONS_sub1= EXPLICIT LIST OF OPTIONS And keep everything as is. No need for sub-packages? No implied OPTIONS_DEFAULT, no nothing. A single line to grep and change. Comment Actions Looks nice, perhaps assign the type of flavor to FLAVOR (i.e., FLAVOR=py2 instead of FLAVOR=yes)? That way you can do 'make -V FLAVOR' in the sub-directory to get the type of flavor. Comment Actions Reading the mailing list thread got me thinking that perhaps adamw is indeed right and we should go for your clean solution, e.g. not create a whole lot of subdirectories for py2-* and py3-*
|