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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
