On Feb 20, 2007, at 16:52, Juan Manuel Palacios wrote:
Finding out which "options" are up for user interaction (and therefore documentable) and which aren't was also one of my explicit goals; comments like yours, "stay away from those!", is what I was looking for with my mail. I didn't get all of them from a standard ports.conf file, I was reading into the bootstrap_options variable that gets initialized in dportinit in base/src/darwinports1.0/darwinports.tcl.
So help me here build the final list. "Options" that are not meant for user interaction and therefore should *not* be documented are:
-) xcodeversion -) xcodebuildcmd -) porttrace -) portverbose (why would you keep this one from being user customizable?)
Please do not touch those.
-) libpath? (from reading dportinit, it seems to me like this is a dangerous one, but you didn't say anything about it)
libpath is simply ${prefix}/share/darwinports/Tcl/ This one could be documented, but I have yet to understand the interest of changing the default value.
-) auto_path? (likewise)
auto_path is a standard Tcl variable, documented in library(n). MP code just plays with it, in particular to append libpath to it.
-) master_site_local (created by jkh in r5004, reportedly as a customizable option meant to "(...) allows portfetch.tcl to go first to a local distfiles cache, if available, before going out over the net to try and get it by less efficient means.", but reading base/src/darwinports1.0/darwinports.tcl around line 450 and base/src/port1.0/portfetch.tcl around line 190 doesn't tell me much what the option does and how I could document it)
This one works like the MASTER_SITE_LOCAL environment variable, and in fact is set to this value during runtime. The value is appended to the list of mirrors before doing a fetch. Jordan might have used this feature at some point, it corresponds to very specific scenarios where you deploy MacPorts on several machines and you host the distfiles somewhere on your local network, for example by sharing a flat version of /opt/local/var/db/dports/distfiles/. I am wondering if anyone (except maybe Jordan) is using that today and might be interested in using it. It still means having a good idea of what is going on in the fetch phase and how to flatten the distributed files. The behavior could be broken with some rewrite of the fetch code that would help us having mirrors, and I would personally not care about maintaining this feature. In a nutshell, I would not document it. Paul