How are per-flavor OPTIONS handled, in a port?

J

jwdevel

It's possible that port X@foo wants one set of options, and X@bar wants a different set.
How is that handled?

One case I have hit, which presumably does it wrong (details follow) is www/py-autobahn
In there, it has the line:

Code: 
    OPTIONS_FILE=           ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options

But what actually happens for me, is that it pops up the "make config" dialog repeatedly, when building related ports. It does not seem to remember that "make config" has been done already. I am using portmaster, so I guess it's possible the problem lies there, somehow? But as I understand it, portmaster basically relies on the underlying "make config-recursive" and such.

Also, I do not see other ports using this "OPTIONS_FILE=..." trickery. I suspect it is not the right approach.

Which comes back to the original question: what *is* the right approach?

I have read this wiki page: https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
and interestingly, one of the few not-yet-struck-out lines is "Figure out how OPTIONS + FLAVORS work."
Perhaps this is not supported, yet? (not that I trust old wiki pages too much, last edited in 2022)

Looking for advice, thanks.
 
SirDice said:
docs.freebsd.org

Chapter 7. Flavors

Flavors are a way to have multiple variations of a port
docs.freebsd.org docs.freebsd.org
Click to expand...

Yes, I have read that — I should have said.
The only mention of OPTIONS on that page is a small note about uppercase/lowercase naming conventions.

That's why I was asking around here and looking at other wiki pages; the handbook seems pretty light on details.

And I have been reading thorough various .mk files too, but there is some mixture of the "old way" of using ports, and what is currently expected/encouraged, and it's hard to tease the two apart, sometimes.
 
Edit... I cannot remove my post it seems but I goofed up... I picked up on your post in the complete wrong way. So sorry about that :/

Best comment I can give: port maintainers are volunteers, best you can do is check the contact info in the Makefile and maybe try to contact them to see if you can help out and come to some kind of solution?
 
Quite a dumb question, but is the OPTIONS_FILE conditionalized?
If not, it could be overridden the ones that appears last, or the one the build specifies.

Can't the pattern like below help?
Makefile: 
...

# Options common throughout all flavors
OPTIONS_DEFINE= opt1 opt2
OPTIONS_DEFAULT= opt1
 
.if ${FLAVOR:U} == flavor1
OPTIONS_DEFINE+= opt3 opt4 opt5
OPTIONS_DEFAULT+= opt3
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/flavor1-options
.elif ${FLAVOR:U} == flavor2
OPTIONS_DEFINE+= opt3 opt5 opt6 opt7 opt8
OPTIONS_DEFAULT+= opt6 opt7
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/flavor2-options
.else
OPTIONS_DEFINE+= opt4 opt5 opt9
OPTIONS_DEFAULT+= opt5
OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/default-options
.endif

...
 
You must log in or register to reply here.
Back
Top