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

[Chris Pickel]

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."
>> }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070622/c3a83081/PGP.bin