Re: What is a FLAVOR and how to unbreak ports?

On 7/26/26 22:30, Mark Millard wrote:
> On 7/26/26 19:43, Steve Kargl wrote:
>> On 7/26/26 18:41, Edward Sanford Sutton, III wrote:
>>>    Flavors are a way to have separate packages created for different
>>> configurations of a port. That way users of pkg do not need to go
>>> manually build software for relatively common software variation
>>> possibilities that they may want or need in place of a single default
>>> set of options.
>>
>> Yeah, I read the porter's documentation.  I could not find where
>> it mentions a comprehensive list of the FLAVORs.  There is no
>> discussion of how one can query for the list of FLAVORs.
>>
>>> On 7/26/26 13:18, Steve Kargl wrote:
>>>> On 7/26/26 12:51, Gleb Popov wrote:
>>>>> On Sun, Jul 26, 2026 at 10:43 PM Steve Kargl <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Updating a laptop that had a year old FreeBSD on it
>>>>>> to top-of-tree.
>>>>>>
>>>>>> % portmaster -Byd --force-config sqlite3 |& tee sgk.log
>>>>>
>>>>> Try updating libclc first using portmaster or plain make.
>>>>
>>>> I did try plain make in libclc.  See the end of original email.
>>>> make dies with an error about llvm15 no longer being supported.
>>>> If llvm15 is no longer supported on fbsd 16, then the libclc
>>>> Makefile should simply skip trying to build for llvm15.

The libclc Makefile's:

.if ${FLAVOR} == llvm15
BROKEN_FreeBSD_16=      Base libc++ is now too fresh for Clang 15 to compile
.endif

seems oddly placed, as worded. It would seem better placed in
devel/llvm15 if the wording is accurate.

I'll also note that stable/15 and stable/14 now are llvm21 based. So
releng/14.5 and releng.15.2 will be llvm21 based, not llvm19 based.

So, if the wording is correct now, the broken list will need to grow
beyond FreeBSD_16 in the future: the libc++ wi update to be like is now
in FreeBSD's main (16).

>>>>
>>>>> Figure out what flavor you need by looking at the installed
>>>>> package's name
>>>>
>>>> That's the question.  What is a FLAVOR and how do I determine what
>>>> FLAVOR is the right flavor?
>>>>
>>>>> pkg info -x libclc
>>>>>
>>>>> If going the plain make route, append FLAVOR=llvmXY to make invocation.
>>>>
>>>> Is there a comprehensive list of FLAVORs?  'man make.conf' does not
>>>> mention FLAVOR.  Is it possible to set FLAVORS there?
>>>
>>>    Flavors are a property of each port individually and not an
>>> externally defined property; some different ports use common flavors
>>> like 'nox11' but there is no hard rule to it. In the ports tree you
>>> can list flavors with `make -C /usr/ports/devel/libclc -VFLAVORS` and
>>> drop - C if you run it in the port's folder.
>>
>> Well, that's inconvenient,
> 
> If one reads enough Makefile notation:
> 
> # grep FLAVORS= /usr/ports/devel/libclc/Makefile
> FLAVORS=	${15 16 17 18 19 20 21 22:L:S/^/llvm/}
> 
> So: llvm15 llvm16 . . . llvm22
> 
> llvm15 is being reported because it is listed first and that is the
> default default-value for a FLAVOR. (There is notation that could be in
> the Makefile to have a different default without adjusting there order.
> There is even notation for finding out what llvm vintage is the
> port-infrastructure's default --but it does not seem to be in use in the
> Makefile.
> 
> I've not kept track of portmaster's notation handling but a common
> notation could be:
> 
> devel/libclc@llvm21
> 
> (as an example). I've not recently checked which value LLVM_DEFAULT has
> as the upstream default ( 19 ?). (I force my own preferences locally.)
> 
> MAINTAINER=     [email protected]
> 
> So: likely no one is keeping the FLAVORS list up to date at the low end
> of the range where folks tend to just stop trying to use the old
> versions. At the upper end it is more obvious when an addition is needed
> and someone takes care of doing so. (Thus, 22 is present.)
> 
>> but that make command should be provided
>> in the porter's documentation.  At the moment, portmaster dies
>> with some mystery error.  Going to /usr/ports/devel/libclc and type
>> 'make' leads to all sorts of fun.  libclc dies because llvm15
>> is no longer supported; so, well, the port shouldn't even try
>> to build that flavor.
>>
>>>    For manually running make, `make -C /usr/ports/devel/libclc
>>> FLAVOR=llvm17` would be an example of overriding it. Not sure if there
>>> are other ways to express it.
>>
>> That's the problem.  There are apparently 8 flavors.  How do I determine
>> I need llvm17 instead of llvm20?
>>
>>>    Some changes I assume should happen:
>>>    1. The default of libclc should be reconsidered if it is broken on
>>> a platform unless it is being actively worked on. Why are we
>>> defaulting to the oldest compiler, a compiler not included as a base
>>> compiler on any supported FreeBSD version, and not even having a
>>> comment as to why?
>>
>> Good question.
>>
>>
>>>> In the old days, one could cd into any directory under /usr/port
>>>> and simply type 'make'.
>>>
>>>    Unless things are broken. Having been building things since 2004,
>>> you can usually find broken things when you look.
>>
>> I've been building ports since its inception.  In fact, I was the
>> maintainer for lang/f2c and few others prior to the creation of
>> portmgr.  portmgr broke lang/f2c, I received daily complaints it
>> was broken, and it only wasted a few weeks of my time trying to
>> figure out what portmgr did.  I dropped maintainership decades
>> ago due to that experience.
>>
>>  at over 30,000 port
>>> folders, its hard to have the tree in a state where 'nothing' fails.
>>
>> Sure, I find a number of issues every time I need to rebuild
>> ports.  I fix/workaround the issue and move on with life.  The
>> math/arpack-ng port now has a mpich and openmpi flavor, because
>> I got tired of editing out the hardcoded use of mpich and asked
>> for either 'none' or 'openmpi' build option.  Unfortunately,
>> math/octave has a hardcoded dependency on arpack-ng@mpich.  Fun
>> times.
>>
>>>> My actual problem is building devel/node24, which dies with an
>>>> error:
>>>> ld.lld: error: undefined symbol: sqlite3session_patchset.
>>>
>>>    I'd have to see a more complete error log to guess properly. 
>>
>> I've found a fix.  It seems that node24 requires sqlite3 built
>> with the sessions compile option set.  For some reason, it was
>> unset when I last built it on my system.  I suppose default
>> options change over time.
>>
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com