ports with bootstrapping dependencies

Landon Fuller landonf at macports.org
Fri Jun 29 23:31:38 PDT 2007


On Jun 29, 2007, at 11:22 PM, Ryan Schmidt wrote:

>
> On Jun 29, 2007, at 13:33, Landon Fuller wrote:
>
>> On Jun 26, 2007, at 11:39 PM, Ryan Schmidt wrote:
>>
>>> On Jun 25, 2007, at 09:46, Taylor R Campbell wrote:
>>>
>>>> There was some recent
>>>> discussion about a `ui_fatal' command by which to fail, although I
>>>> understand that it was simply a proposal not yet implemented.  Does
>>>> this sound plausible, however?
>>>
>>> Not really needed, though, either. Just do ui_error "the message"  
>>> followed by exit 1. And, again, do this in the pre-fetch phase.
>>
>> Calling "exit" from a Portfile will cause any front-end using the  
>> dports API to exit, no? That seems bad form.
>
> I was under the impression that doing this within the pre-fetch  
> phase was acceptable. I thought we discussed this on the list  
> earlier. Many ports do this: xorg, wine, mozilla, sockstat, ipcs,  
> gauche-gtk, mysql5-devel, TeXShop.

It will still cause the entire front-end to exit, rather than  
throwing an error in the port sub-interpreter. It's the equivalent of  
a library calling abort() instead of returning an error code.

> If that's not ok, then we really do need someone to implement  
> ui_fatal. But what would that do differently?

return -code error "An error, here"

It's still not perfect, in that it's simply not declarative -- how do  
I determine whether a port can run on my system ? Execute the fetch  
phase.
However, It's still better than exit.

> There are some ports that still do it directly in a platform  
> selector: xloops, nestedsums, cln, GiNaC, hugs98, ghc, klisp,  
> kdelibs3. I can see how that's indeed wrong and needs to be changed.

I'm surprised at the extent of the usage.

-landonf



More information about the macports-dev mailing list