Re: Adding zlib to GCC

[Nick Burrett <nick at dsvr dot net>]

Marc Espie <espie@quatramaran.ens.fr> writes:

> In article <3644.967502382@upchuck> you write:
> >Long term I'd like to see this happen; however, recent developments with
> >the FSF lead me to believe this will meet with a fair amount of resistance
> >from RMS and the FSF in general.
> 
> There is the `release' issue raising its ugly head again.
> It's already rather hard to cobble together a *stable* distribution of 
> toolchain tidbits, if you want to merge common parts (to wit: gdb,
> binutils, gcc, with respect to libbfd and libiberty). If there is a common
> repository, I don't really see agreement as to synch'ed releases between
> these.
> 
> So, yep, a common repository is just very good and simple for development.
> But unless there is a clean solution to the release issue (such as an 
> actual release schedule, with reasonablly fast turn-around... six months
> to one year, and where *everything* in this repository meets release 
> *every time*), this wrecks havok for individuals, and distribution 
> assemblers.
> 
> Not saying this can't be done, but do you have any thought on how to achieve
> such a feat ?

Yes. I'd been thinking about this only last week.  I reckon that the neatest
solution would be to extend the functionality of CVSROOT/modules so that
directories in external repositories could be referenced, and optionally
include a tag.

Once appropriately configured, `$ cvs update -Pd' would automatically track
the release branches of gdb, binutils, zlib etc. so you shouldn't have to
bother about the release issues.

It is probably a lot easier to hack CVS than have to workaround RMS, the FSF
and use development code.

Regards,


Nick.