On 22 Jun, 2007, at 18:57, Jordan K. Hubbard wrote:
That seems a lot more complicated than my ui_fatal procedure suggestion. :-)
- Jordan
It's also a lot more complicated than method used in the portfile I linked to in my original message (fusefs [1]), which as you might note, already exhibits the proper behavior in interactive mode :) Chris [1] http://trac.macosforge.org/projects/macports/browser/trunk/dports/ fuse/fusefs/Portfile
On Jun 21, 2007, at 1:48 PM, Ryan Schmidt wrote:
On Jun 21, 2007, at 15:14, Landon Fuller wrote:
On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a platform statement? Please do so only within a stage such as pre-fetch, e.g.:
platfrom darwin 7 { pre-fetch { ui_msg "GiNaC is not supported on Panther (OS X 10.3.x)." exit 1 } }
Otherwise, people running port info, portindex, etc. on darwin 7 will be inconvenienced by the exit.
Sorry; I didn't see Chris already made these points.
It really bears re-iterating though. Calling exit(1) in a Portfile is just bad news, at any stage. Maybe we should remove that procedure from the Portfile Tcl interpreter ...
Well, true, but the only reason anyone's using it is to handle the situation where a port is incompatible with some OS version or some processor architecture. If we had a way of specifying that in the portfile syntax, then we wouldn't need to call exit. It would also have the advantage of standardizing the message that gets output to the user in these situations, rather than leaving it up to the portfile author in each case. Hmm.... Maybe
platform darwin 7 { incompatible }
? Based on the auto-selected platform variant, MacPorts could then construct nice error strings.
However, this wouldn't address an earlier concern of mine: why is a port incompatible with an OS? Is the OS too old or is it too new? We might have ports that need both situations. We could say
platform darwin 7 { incompatible too_new }
where the default is too_old. Or we could say
platform darwin 7 { too_new }
But that still doesn't tell the user which OS version(s) would be acceptable. Maybe we should think differently... not a platform variant, but some other directive:
darwin.minimum 7 darwin.maximum 8
One could specify either or both (or none) of these. This would satisfy all variants, and would enable MacPorts to construct helpful messages to the user. ("Sorry, ${name} requires at least Mac OS X 10.3." or "Sorry, ${name} only works on Mac OS X 10.2 and earlier.")
Doesn't address the processor architecture issue... that could still be
platform i386 { incompatible }
("Sorry, ${name} is not compatible with Intel processors.")
There could even be some options:
platform i386 { incompatible temporary }
("Sorry, ${name} is not compatible with Intel processors at this time.")
platform powerpc { incompatible permanent }
("Sorry, ${name} is not (and will never be) compatible with PowerPC processors.")
Finally.... maybe we could still allow the port author to either add to or replace the default message.
platform powerpc { incompatible permanent "Sorry, ${name} is written in Intel assembly code, so it cannot work on PowerPC processors." }