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