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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev