Don't call exit (again) (was: Re: [26399] trunk/dports/math/nestedsums/Portfile)

[Jordan K. Hubbard]

That seems a lot more complicated than my ui_fatal procedure  
suggestion. :-)

- Jordan

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."
> }
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev