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