Page MenuHomeFreeBSD

Very simplistic and minimal initial version of flavors
AbandonedPublic

Authored by bapt on Dec 18 2016, 9:59 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 24, 7:03 AM
Unknown Object (File)
Thu, Nov 21, 2:21 AM
Unknown Object (File)
Wed, Nov 20, 2:17 AM
Unknown Object (File)
Fri, Nov 15, 10:29 AM
Unknown Object (File)
Sep 27 2024, 4:57 PM
Unknown Object (File)
Sep 8 2024, 10:27 PM
Unknown Object (File)
Sep 7 2024, 8:24 PM
Unknown Object (File)
Sep 1 2024, 12:00 AM

Details

Reviewers
None
Group Reviewers
O5: Ports Framework(Owns No Changed Paths)
portmgr
Summary

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

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 6309
Build 6549: arc lint + arc unit

Event Timeline

bapt retitled this revision from to Very simplistic and minimal initial version of flavors.
bapt updated this object.
bapt edited the test plan for this revision. (Show Details)
bapt added a reviewer: portmgr.

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

Mmmm, so, one depends on a flavored port by doing bar:foo/bar/flavor.

How do I depend on a port, whatever its flavor ?

In D8840#183126, @mat wrote:

Mmmm, so, one depends on a flavored port by doing bar:foo/bar/flavor.

Yes

How do I depend on a port, whatever its flavor ?

That is not possible yet (this is the next step)

kevans added inline comments.
Mk/bsd.port.mk
1174

Hi,

I think this is not necessarily correct, perhaps? Scenario:

  • editors/vim absorbs editors/vim-lite
  • creates 'lite' flavor directory, adds FLAVORS= lite full as expected
  • for simplicity's sake, FLAVOR?= in editors/vim/Makefile

This seems possible and likely with the current setup, but this default may not go so well if they're building the full flavor that the port could default to.

Mk/bsd.port.mk
1174

Ohh, apologies, I misread the other bits.

antoine added inline comments.
audio/py-al/py2/Makefile
4

can this be changed to python:2.7 (don't require the python2 metaport)

audio/py-al/py3/Makefile
4

and can this one be change to python:3.3+ (don't require the python3 metaport)

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
OPTIONS_sub2= ANOTHER 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.

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.

Mk/bsd.port.mk
1056

Spelling police :)
IGNORE= Flavored port, please build in one of the flavored directories: ${FLAVORS}

1175

Would it be more efficient or readable to write this instead?

.if defined(FLAVOR)
MASTERDIR?= ${.CURDIR:H}
.else
MASTERDIR?= ${.CURDIR}
.endif

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-*

bapt added inline comments.
audio/py-al/py3/Makefile
4

I don't like much this approach the goal is to have only 2 sets of flavors, maybe we should modify it so that python:3 depends on the default python 3 (same for python 2)