Bug 164638 - [bsd.port.mk] [patch] architecture and OS version dependent port building
Summary: [bsd.port.mk] [patch] architecture and OS version dependent port building
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Port Management Team
Depends on:
Reported: 2012-01-30 15:50 UTC by Matthew Seaman
Modified: 2019-09-04 13:52 UTC (History)
0 users

See Also:

not_for_archs.diff (38.05 KB, patch)
2012-01-30 15:50 UTC, Matthew Seaman
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Seaman 2012-01-30 15:50:10 UTC
This is a respone to Mark Linnimon's message here:


It does basically three things:

  * Removes the NOT_FOR_ARCHS variable and associate functionality.

  * Creates a new BROKEN_OSARCHS variable.  This is largely syntactic
    sugar, meaning that it is no longer necessary to use
    .include <bsd.ports.pre.mk> in order to test ${ARCH} or ${OSVERSION}

  * Creates a new SUPPORTED_OSARCHS variable.  This allows maintainers
    to indicate which architectures they will support, and whether the
    package build cluster should routinely build packages for that port.

Now for the more long-winded explanation bit....

NOT_FOR_ARCHS is frequently misused to indicate temporary build or
installation failures on particular architectures.  The _FOR_ARCHS stuff
should be really only be used to indicate ports designed to work on
specific CPU architectures.  ONLY_FOR_ARCHS exists for this purpose.
The problem with extending it to cover temporary failures is that the
package build cluster will never retry building that port, so there's no
way to tell if changes to the toolchain or updates to the port have
subsequently fixed the problem.

This is where the BROKEN_OSARCHS variable is useful.  This is a list of
achitecture-OS version pairs corresponding to the different environments
used in the package build cluster.  Thus you can easily mark a port as
broken on sparc64-7, rather than having to use a construction like this:

.include <bsd.port.pre.mk>

.if ${ARCH} == "sparc64" && ${OSVERSION} < 800000
BROKEN= compiler dumps core

.include <bsd.port.post.mk>

(Not using bsd.port.{pre,post}.mk so much should help a bit with index
building times too.)

It's also rather easier to grep for BROKEN_OSARCHS than it is for a
construct like the above.

As BROKEN_OSARCHS ultimately uses the pre-existing BROKEN variable,
setting TRY_BROKEN will allow these ports to be retested.

Finally there is SUPPORTED_OSARCHS, which can be used to indicate policy
about where a port is known to usable.  For regular users it doesn't do
anything except print a warning message if an attempt is made to compile
a port on an unsupported architecture/OS combination.
For the ports build cluster, conditional on PACKAGE_BUILDING being set,
it turns off building on unsupported environments by setting IGNORE.

As the patch stands at the moment, every port will be using the default,
which is to support these architecture/OS combinations:

i386-7 i386-8 i386-9 amd64-7 amd64-8 amd64-9

but the defaults can be modified easily or port-specific settings can be
added.   There is also a TRY_UNSUPPORTED knob to turn on building
packages on all architectures / OS versions.

Finally, all this testing the CPU architecture and the OS version makes
no sense at all for ports that don't install any compiled binaries, such
as shell scripts.  Those ports can define a variable ARCH_INDEP to opt
out of the SUPPORTED_OSARCHS thing altogether.
Comment 1 Edwin Groothuis freebsd_committer 2012-01-30 15:50:21 UTC
Responsible Changed
From-To: freebsd-ports-bugs->portmgr

bsd.port.mk is portmgr territory (via the GNATS Auto Assign Tool)
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2014-06-02 02:53:38 UTC
Infrastructure PR.
Comment 3 Baptiste Daroussin freebsd_committer 2019-09-04 13:52:39 UTC
many helpers have been added in the mean time which covers most of the proposals here.