On Jul 7, 2013, at 13:51, Mark Anderson wrote: > Yeah. That was why I sort of just floated it as an idea. Mainly because of my > troubles with a certain OSX that is not to be named or the fiery NDA demons > will smite me. > > And now that you mentioned curl and subversion it's making more sense to me, > since Macports likes to rely our own stuff to maximize compatibility.
Thus far, MacPorts *ports* like to rely on other MacPorts ports for maximum compatibility and consistency between OS releases. However, thus far, MacPorts *itself* has never relied on MacPorts ports. In fact, just naively making MacPorts base link with libraries provided by MacPorts ports would be brittle and unwise, e.g. if MacPorts base used a library from MacPorts cURL, and the user deactivated MacPorts cURL, then MacPorts wouldn't be able to use cURL anymore. But as I said it's possibly worth looking into ways of solving it. For example, a person preparing a MacPorts base release could use MacPorts to build cURL, and then include that pre-built cURL in the MacPorts installer, which would install it into a secluded location and which would only be used by MacPorts itself. A separate problem, but one which including our own libraries for cURL, Tcl, Subversion and so forth might be a step toward solving, is the ugliness of having a separate MacPorts installer per version of OS X. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
