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

[Ryan Schmidt]

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."
}