Re: GC-optional mode: does anyone care?

[Sebastian Reitenbach]

On Saturday, May 28, 2011 12:19 CEST, David Chisnall <theraven@sucs.org> wrote: 
 
> 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.
I don't know how much the performance overhead would be with this option, I 
think on recent hardware, nobody would care, but on older hardware I thougth it 
may be noticable? In the ports makefile, I can distinguish between 
architectures, but then only adding this complexity for slower architectures, 
would make no sense. Then this complexity could be added in general for all. 
Either way, if I could get both in one run, either with GC-optional mode, or 
with creating both versions in parallel, would be the easiest.


> 
> 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).  



Sebastian


> 
> David
> 
> -- Send from my Jacquard Loom
>