Bug 255185 - ports-mgmt/portfmt: portclippy not recognizing some OPTIONS_EXCLUDEs
Summary: ports-mgmt/portfmt: portclippy not recognizing some OPTIONS_EXCLUDEs
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Tobias Kortkamp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-18 14:19 UTC by Jimmy Olgeni
Modified: 2021-04-18 15:21 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (tobik)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jimmy Olgeni freebsd_committer 2021-04-18 14:19:20 UTC
While cleaning up the Erlang ports I noticed that portclippy does not recognize the OPTIONS_EXCLUDE_powerpc64_11 variable due to the "_11"; OPTIONS_EXCLUDE_powerpc64 is recognized correctly.

Therefore, all version-specific EXCLUDESs end up in the unknown variables section of the warnings.

How to reproduce: run "portclippy Makefile" in lang/erlang :)
Comment 1 Tobias Kortkamp freebsd_committer 2021-04-18 15:17:33 UTC
The framework does not know about OPTIONS_EXCLUDE_powerpc64_11 either.
It does know about OPTIONS_EXCLUDE_powerpc64 because that is something
that's actually hooked up in bsd.options.mk.

Basically this is a custom variable that the port defines for itself.
The only place it is referenced is in OPTIONS_EXCLUDE_powerpc64 in the
port itself. Portclippy cannot reify variables yet. I have no timeline
as to when or if that will change, so the best I can suggest for now
is that you prefix it with an underscore _. Then it will be ignored by
portclippy.

OPTIONS_EXCLUDE_powerpc64=      ${OPTIONS_EXCLUDE_${ARCH}_${OSREL:R}} HIPE
OPTIONS_EXCLUDE_powerpc64_11=   DTRACE
OPTIONS_EXCLUDE_powerpc64_12=   DTRACE

to

OPTIONS_EXCLUDE_powerpc64=      ${_OPTIONS_EXCLUDE_${ARCH}_${OSREL:R}} HIPE
_OPTIONS_EXCLUDE_powerpc64_11=  DTRACE
_OPTIONS_EXCLUDE_powerpc64_12=  DTRACE
Comment 2 Jimmy Olgeni freebsd_committer 2021-04-18 15:21:39 UTC
That's true! I didn't notice the reference above - thought it was something standard. Never mind :D

Thanks!