Hello! I'd like to make a port for MIT Scheme, an implementation of the Scheme programming language. The port is somewhat complicated, though, because of a bootstrapping process. However, I think that I have found a way to make the bootstrapping process work without introducing circular dependencies, which requires only a small change to MacPorts' dependency specifications. MIT Scheme is a large program written primarily in Scheme, and based on a native-code compiler. This would mean that building it is impossible without an older version of itself, but its compiler also has a C back end, and the next snapshot to be released very shortly will support the construction of distributions with pre-generated C code by which the whole system can be bootstrapped. This means that it is easy to write a port that just fetches a tarball with the generated C code and bootstraps the whole system from that. The trouble with this is that it is very slow, and only the C back end can be built from generated C code. I'd like to have another port for the native back end, so I'll call the port with the C back end `mit-scheme-c', and the port with the native back end `mit-scheme-native'. Building Scheme from scratch is slow (requiring about an hour or two on my 2 GHz MacBook), and building either back end with the other back end is also slow (C -> native or native -> C). If the user already has an older version of either back end, then upgrading to a newer version can run much faster (about ten or twenty minutes for me). In an ideal world, I could have two portfiles, something like <http://people.csail.mit.edu/riastradh/tmp/liarc-Portfile> and <http://people.csail.mit.edu/riastradh/tmp/native-Portfile>: mit-scheme-c has three variants, all of which are mutually exclusive, and which I'll write with a `+' prefix just to visually distinguish them from port names: +from-scratch requires nothing but a C compiler and an operating system, fetches a tarball containing pre-generated C files, and bootstraps the whole system from that. Slow. +from-c requires mit-scheme-c (usually an older version), fetches a pristine source tarball, and just builds the system, without any extra intermediate bootstrapping stages. Decently fast. +from-native requires mit-scheme-native, fetches a pristine source tarball, and bootstraps the system with an intermediate cross-compiler. (This one isn't actually very useful; it does more work than +from-scratch, because it has to prepare what was pre-generated for +from-scratch.) mit-scheme-native has two variants, both of which depend on an existing installation: +from-c requires mit-scheme-c, fetches a pristine source tarball, and bootstraps a native compiler from that. Slow, but this is the only way to get a native system to begin with. +from-native requires mit-scheme-native (usually an older version), fetches a pristine source tarball, and builds the system without any extra intermediate bootstrapping stages. Fast. Unfortunately, `mit-scheme-c +from-c' and `mit-scheme-native +from-native' don't work because of the obvious bootstrapping problem. I discussed the issue with Juan Manuel Palacios and Eric Hall on IRC, and was informed that the dependency engine would require an inordinate amount of work before this kind of nearly circular dependency would work at all. However, it occurred to me that we could somewhat dangerously work around the *port* dependency by rendering it into a *binary* dependency -- that is, the +from-c variants depend on the existence of a binary called `mit-scheme-c', and the +from-native variants depend on the existence of a binary called `mit-scheme-native'. MacPorts do have a way to specify a dependency on a binary file by some name -- `depends_* bin:foo:bar' --, but it requires a port to be associated with the file. What I need for MIT Scheme is *almost* this: if the file isn't there, I want MacPorts not to try to build the port associated with it, but just to give up; users shouldn't use the +from-c or +from-native variants if they aren't available. What I propose, then, is to allow a dependency of the form `bin:<filename>', without an associated port (or perhaps with `I-know-what-I-am-doing' or `just-complain-to-the-user-if-unavailable' instead of a port). Although it is slightly dangerous to do this, it's a very small change that lets us work around what would otherwise appear to be circular dependencies, and it would mean that upgrading the MIT Scheme port could take fifteen to thirty minutes, rather than anywhere from two to four hours. Thoughts? Does this sound reasonable? Is there another way to go about this that I hadn't thought of?