On Jun 30, 2007, at 01:31, Landon Fuller wrote:
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.
Sure... but I don't know the MacPorts base code well enough (or at all) to know what the implications of that are.
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.
Oh yes, now I remember seeing that "return" syntax used a couple places (libiconv, py-psyco, ghc-devel, sshfs, libfuse, fusefs) and not really understanding it. But so we should be replacing things like pre-fetch { ui_error "foo bar" exit 1 } with pre-fetch { return -code 1 "foo bar" } Yes? This will work the same? So long as you say that's what we should be doing, it shouldn't be too much trouble for me (or another volunteer?) to go through the ports listed in this email and fix things.
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.
There are lots more ports that call exit but for other reasons so I didn't list them in the earlier mail. For example, kdelibs3 says: pre-configure { if {[file exists ${prefix}/bin/cups-config]} { ui_msg "port:cups-headers may prevent building this port." ui_msg "Please uninstall (or deactivate) cups-headers and restart the build." exit 1 } } To convert such multiline messages to return -code 1 "foo" syntax I guess we can use a "\n" to do the newline?