On my PowerPC machine with 10.4 it works fine. Toporobot you may find here: there was a version for MacOSX, but I'm not sure if it will work. But in combination with DistoX and PocketTopo it is really a dream of cave surveyor. It is not so big problem, but for Mac only user a bit complicated. Please, don't forget the therion which must be compiled and there must be installed several other programs (all free). I do not know what you would do for graphics iwth it.
If you are up to compiling your own copy of a progran, the Survex code is available. ) How do you plan for such checks to work? Do the just warn or bail out? (I'd prefer the former).Bob Thrun wrote:Martin Heller's Toporobot is available only in a Mac version. ) I think it would be better to implement such check at the macports1.0 level, probably as a part of the mportinit proc (so that any client initializing the API gets the safety check for free) or as a proc of its own in the macports1.0 namespace (preferable in my opinion, so that an API client is free to decide whether to check up-to-date'ness or not, as there are some clients that might not need it - cf. A comment and a couple of questions, though: check for "gcc" before running a build, for instance)Ī runtime check for an up-to-date OS and dev tools package would indeed be great. It now needs a matching runtime check when running port(1), to see that the required tools are installed and up to speed (e.g. Alternately, Blair says Fink contains code that identifies specific bad versions of gcc, which we could look at doing too.
We know at this point that Xcode 1.5 and 2.4.1 are fine for Mac OS X 10.3.9 and 10.4.10, respectively, so any Xcode versions earlier than those should trigger the new behavior.
Landon objected to the latter saying users will be put off by such a large download, but Blair countered that developer time is valuable and we shouldn't waste it trying to re-solve problems that we already know are solved by upgrading Xcode. It should either print a warning when the Xcode version is known to be outdated, or it should refuse to proceed altogether until it's updated. MacPorts should catch this before it ever gets to Trac or the mailing list. Both issues were resolved by installing Xcode 2.4.1. This happened recently in #12219 where someone couldn't install gcc42, and on the mailing list someone reported being unable to install wine. Then they run into weird problems that we waste time investigating.
We have the problem that from time to time, although we say in InstallingMacPorts that people must install the latest Xcode, they don't, and they end up using an older Xcode.
0 kommentar(er)
