2011/4/1 Baptiste Daroussin <baptiste.darous...@gmail.com>: > 2011/4/1 Eitan Adler <ead...@freebsd.org>: >> Hi, >> >> 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 >> _______________________________________________ >> 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" >> > > Removing the option framework is an option if it is replaced, by > something equivalent, I have proposed > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/152568 for example > but it needs time to be reviewed by portmgr. >
The best work done ever to the ports tree. > This new implementation of option is more consistent and cleaner. > > The slave ports is not a solution only to make sure we have a port > with a given option set, but it is also a way to avoir code > duplication (php for exemple). > > pkgng can register this options passed to a port to an installed > package, along with my option framework proposal, it would allow us to > be able to check the configuration of a given port from the port > infrastructure. > And it just rocks! :-) > My 2c, > Bapt > _______________________________________________ > 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" > -- Demelier David _______________________________________________ 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"
