Removing Cruft from the ports tree

Eitan Adler eadler at
Fri Apr 1 03:55:24 UTC 2011


    I’m been working recently on a series of PRs that called “Reaper
of the Dead” PRs. I have been going through the various build files we
have (for source, docs, and especially ports) and attempting to remove
dead code, old cruft, and unneeded checks. Some examples include
ports/155543, ports/155511, ports/154395, conf/155737, and
conf/155738. My goal has been twofold: making it easier to understand
what is going on, and speeding up the process without requiring
significant change.

    One of the features that has given us the most trouble has been
the options framework for ports. We automatically test ports using the
default options, but we are unable to perform automated using every
combination of options. A port with just four options has sixteen
possible configurations, and some ports have more than that. Even
supporting one option might double the number of things to test.

    However some ports rely on specific configurations of options of
other ports. In order to deal with this mess we have come up with a
hack: slave ports. We have entire ports that are designed just to
change the default options for other ports. This requires a
non-trivial amount of code on the bsd.*.mk files to support.

    Automated configuration is not the only thing that has caused us
trouble in the past. We routinely have to do deal with questions from
inexperienced users on questions@ and ports@ details problems with
non-standard configurations. Many times the solution to a ports
related problem is flipping a bit in the options file.

    I propose removing the options systems entirely. While it does
serve a small purpose of allowing customization for some end users, I
believe the flaws outweigh the benefits. Removing the options
framework would enable us to remove over 500 lines of expensive code
from the ports system. Not only that but because maintainers would be
able to choose the best possible configuration for the their port
users would no longer have to mess around.

    While I understand there might some minor part of the community
that has a sentimental attachment to the blue-on-gray-on-blue
configuration, and still others want to prematurely optimize, a simple
workaround could be implemented. We can allow users to add their own
./configure arguments to the makefile. This serves the needs of the
community while allowing us to deal with a simpler and more reliable
ports system.

    Feel free to express your thoughts here. I would like to get this
hashed out now so the process could occur on a later date(1).

Eitan Adler

More information about the freebsd-ports mailing list