Hi,
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 like .if !empty(.CURDIR:M*/ports/foocategory/barport*) WITH_BAZ=YES BAZ_OTIONS=... .endif 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, Klaus _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
