On Nov 5, 2008, at 10:27 PM, Ryan Schmidt wrote:
Hypothetical additional phases before the fetch phase would not
cause problems for the existing strategy. The point of checking and
bailing before the fetch phase is that we don't want someone
downloading a large file if we already know they won't be able to
install it.
Hmmm. I'm still not sure why it is we're failing so spectacularly to
communicate here, but I'll try one more time: Blowing out of, say, a
platform check could be reasonably expected to happen even before
fetch, since who knows how expensive that hypothetical additional
"sniff" target in my example is going to be? There's no point in
executing it if the port is not even valid for that platform and
*that* is the point. This really does not have anything at all to do
with fetch and you are, for some reason, are simply displaying an
unusual love for that particular target. :-)
That will cause that error to be printed for *any* port command
relating to that port, even a port command that we do want the
user to be able to execute, such as "port info".
Sounds like you've simply found a bug there, actually, since I
can't see any argument in which that could be deemed "correct
behavior". You should open a ticket. :)
I don't consider it a bug... It's natural that MacPorts would have
to parse the entire Portfile in order to do any port command.
Well, not everything you parse necessarily gets run in the case of a
dependent port, but in this particularly case I was wrong anyway
since the platform statement would fall under the category of
something you have to execute unconditionally and you'd still blow up
with that -error every time, so "never mind" on that particular point,
you're right, it's not a bug.
I don't doubt that could be done. :)
Careful. Such enthusiasm could be infectious. ;-)
- Jordan
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
