Prev: Current unassigned ports problem reports
Next: FreeBSD Port: php5-5.2.11_1 upgrade path to 5.3.0/1
From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= on 7 Dec 2009 10:42 Anyone who uses config-recursive more often than once a year knows that it's broken. Or at least they know it needs to be run multiple times until it doesn't show options dialog. While some people might just live with it, I think it should be fixed properly, and so did the person who introduced this target: "it sufficed to run config-recursive twice to catch all of the dependancies I had configured. Maybe we can figure out how to it all in one pass later"[1]. The "later" is now, almost 5 years after config-recursive was first introduced [2]. As I was complaining on IRC how many times I had to run config-recursive to finally config gnome2, someone told me "just rewrite it". And I did... Probably the only reason this wasn't fixed earlier is that no one was annoyed enough to write a patch. The patch changes config-recursive so that it does a dependency check right after config is saved for a particular port, effectively configuring only the ports that are needed and configuring all dependencies in one pass. rmconfig-recursive is not exactly ok either. Actually, it's even more complicated. It removes all saved options for a particular port and its dependencies. However new dependencies that were previously disabled are introduced. Since rmconfig-recursive doesn't know about them during first pass, it doesn't remove their options, creating a similar situation to config-recursive. I'm not sure what to do about rmconfig-recursive, because: 1. Some users may not like if there are changes in how it operates. 2. It's a pain to make it "do the right thing" without slowing it down or making its output slightly different from the original. However, I believe it's pretty safe to assume that if user is doing rmconfig-recursive, he wants to clear options for all dependencies, both currently selected via options and the default ones. But here's a catch: there are options that are not enabled by default, not selected by user, but may be configured already. I chose not to do anything with them, because unconditionaly removing config for all possible dependencies could wipe most of options user has ever set. It would be possible to remove options for all possible dependencies only when something like RMCONFIG_ALL is defined, but then it would do something similar to "rm -f /var/db/ports/*/options", except much slower. I've added changes to rmconfig-recursive to the patch, it's now slighly slower than it was before, however still faster than running it twice or no-idea-how-many-times. rmconfig-recursive now removes config for current and default dependencies. I've also added rmconfig-internal target, to be used by rmconfig-recursive. It's very similar to rmconfig, but simplified and its output is intended to be used by make itself rather than be human readable. Target showconfig-recursive is fine, since it doesn't really do anything with options. My [rm]config-recursive is heavily based on all-depends-list, so it may help understanding my patch better if you read and understand that target first. Patch should be ok, but since it was rewritten and/or edited many times, I may have left some unnecessary or otherwise wrong code. I'd appreciate feedback and testing, if everything goes well I'll submit a pr for this. 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=76254 2. http://lists.freebsd.org/pipermail/freebsd-ports/2004-December/018765.html -- Andrius
|
Pages: 1 Prev: Current unassigned ports problem reports Next: FreeBSD Port: php5-5.2.11_1 upgrade path to 5.3.0/1 |