ports with bootstrapping dependencies

[Ryan Schmidt]

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?