Removing Cruft from the ports tree

Klaus T. Aehlig aehlig at
Tue Apr 12 09:41:27 UTC 2011


I'm disappointed that there are plans to remove the ports framework. I
always considered this to be one of the very strong points of the ports
infra structure, precisely because I believe...

> 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.

...there is no "best configuration" for every port. It depends a lot
depends on what you use your machine for. On my desktop I care for full
features, on my laptop for little dependencies, servers WITHOUT_X11, ...

Or, what I've been recently doing in my day job. There probably is no
"best" implementation of the message passing interface; that's why there
are different MPI Implementations in the ports tree (e.g., openmpi,
mpich2, ...). Now there are a lot of scientific libraries (mainly in
the math and science category) that also support MPI. To benefit from
this, I need them to build against the same mpi implementation (because
I use several of them in the same executeable). There I found it very
convenient, that the WITH_MPI and WITH_OPENMPI options from /etc/make.conf
were honored, and that I could easily switch between MPI implementations
just by changing a few configurations and rebuilding.

Maybe I misunderstood your sugesstion. I'm not saying we need the blue
dialog boxes. I'm pefectly happy with configuring ports by adding things

.if !empty(.CURDIR:M*/ports/foocategory/barport*)

in /etc/make.conf or any other means of chosing what I need. What I'm
saying is, that we're losing a lot, if we give up the possibility of
ports to install different sets of files and register different sets
of dependencies depending user configuration; just diffent configure
arguments are not enough. I know, it is a lot of work to support the
different builds for a single port, but I think it's worth is; especially,
as it is probably not less work (but more confusing for the user) to
multiply each port for the different options (e.g., the mpi implementation
used -- or maybe without mpi for serial computations).

Best regards,

More information about the freebsd-ports mailing list