Re: GC-optional mode: does anyone care?

[David Chisnall]

On 28 May 2011, at 11:10, Sebastian Reitenbach wrote:

> So if I get it right, I'd need to create two versions for each 
> library/framework, one without, and one with gc, so that apps, which would 
> use one or the other method can both work.

Yes.

> Speaking for OpenBSD packages, I think I'd favor the third option you 
> proposed, if both could be created with one compile run. Then I could just 
> install both versions, and I'm done. The apps would pick then one or the 
> other, whatever they need.

The problem with this approach is that it would require a significant change to 
how you specify libraries in GNUmakefiles.  We'd have to specify a list of 
frameworks, rather than a list of linker flags (this is something I'd like to 
see anyway, because it's irritating having to have conditional code for every 
framework specifying -framework on OS X and -l everywhere else).  -make would 
then have to append the GC suffix for the GC version.  

The relative advantage of the GC-optional mode is that you'd just be able to 
add -fobjc-gc to OBJCFLAGS and forget about it.

That said, I'm not really sure how big of a problem this is.  For the GNUstep 
core packages, it isn't much effort for packagers to create GC and non-GC 
packages.  Apps / tools will only need to ship in one flavour. The only place 
where it may actually be useful to support both easily is in downstream 
frameworks, but these would have to explicitly opt in to GC support (we don't 
want to be automatically building GC-enabled versions of code that won't work 
with GC).  

David

-- Send from my Jacquard Loom