[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] Re: Healing the fork.

From: Rob Landley
Subject: [Tinycc-devel] Re: Healing the fork.
Date: Wed, 9 May 2007 01:13:40 -0400
User-agent: KMail/1.9.1

Going through the web archive to see what I missed, I see David Wheeler's 
post, which he emailed the gist of to me earlier:

> Here's a proposal for healing the fork; comments?
> Rob Landley's been doing some stellar work with tinycc on his fork, but he
> loathes CVS and likes Mercurial.  Fabrice Bellard would like to continue to
> use CVS and have tcc's code hosted on Savannah (which is backed up, and
> people currently pull from it).  I've been creating a number of patches,
> and I want to have a _single_ "official" tcc line because forks are a big
> pain (they divide effort!). I suspect others have the same hope of a single
> maintained codebase.
> So I've asked Fabrice Bellard for permission to update the tcc CVS
> repository on Savannah, and he's agreed (crazy man!). Here's my current
> idea: * Wait for Landley's fork to merge in all the capabilities of the
> current CVS repository (e.g., "-E").  I believe Rob Landley is working on
> that, and hopefully that will be done "soon".

It's in.  Now that the website's back up... :)

> * Apply a change to the CVS repository to resync Landley's fork and CVS (to
> their common root), and then apply each of Landley's changesets (I'll write
> a script to do that).  That will mean that the CVS repository will end up
> with a duplicate of Landley's fork, including as much of its history that
> CVS can manage.

As I pointed out earlier, I moved several files (and would like to move more, 
but functionality takes priority over cleanups for the moment).  This is 
going to confuse the HECK out of cvs...

> After that, for as long as Rob Landley is willing to maintain his fork, I
> intend to quickly look at each change in his fork and reapply it to CVS
> unless it's completely insane.

I'm happy to maintain my fork for a longish time, but I'm still amazed anybody 
thinks I know what I'm doing.  It's out there for anybody to use and I'll do 
the best I can with it, but other people "checking for completely insane" is 
a good idea, yes. :)

> Conversely, I'll ask everyone (including 
> me) to submit patches to Rob Landley _first_.  Frankly, I suggest posting
> each patch to the mailing list, so everyone can kibitz.  Fabrice obviously
> need not submit changes to Rob Landley, though there might be merits in
> doing so (that's his decision!).

Getting Fabrice to spend time on tcc again would be enough of a coup that I 
wouldn't quibble about how.  That said, extracting multi-file patches from an 
active CVS repository is a serious pain.

> This process will mean patches will get 
> lots of review, and it'll mean that the code is stored in Savannah (which
> gets backups, is already used by distributors to extract code, etc.).
> Landley's fork now includes a host of fixes, including 8 from me. I think
> the following to-do items are especially important:
> * alloca() support for x86 (I posted a start towards that)
> * Run on current Ubuntu (this involves visibility issues)

I also have a "breaktcc.c" somebody sent me that tcc segfaults trying to 
compile.  (Attached.)  Haven't had a chance to look at it yet...

I think I've now gone through everything linked from the wikipedia tcc entry 
and merged it.  Still haven't tackled the TODO list in the source.

> * Merge Fabrice Bellard's latest changes into Landley's fork (e.g., "-E")
> as appropriate


> * Fix stringify (there's already a post with patch that is believed to do
> this).

I'm reviewing that patch.  I'm hoping there's a sane way to do it with less 
extra function parameters sprinkled everywhere, but I only had time today to 
read about 8 more pages of my big 205 page printout of tcc.c I made last 
year.  (In a 3-ring binder and everything.)

> Once those to-do items are done, I think we should talk about testing and
> releasing.  Rob Landley just made a release, but a lot will have happened
> since then!

Release early, release often.  A release is just a known checkpoint at which 
it worked for the person releasing it and it had a finite set of bugs.  
(Releases aren't moving targets the way source control is.  They don't 
spontaneously regress.  This is a good thing.)

> Comments welcome.  Does this make sense?

I have no objections, of course. :)

I point out that mercurial is designed to be distributed.  Anybody who wants 
to clone my repository and do their own changes is welcome to, although I 
have yet to master this whole "pulling" thing and am likely to just cherry 
pick patches for the moment.  Patches on the list is good, people poke me if 
they stay on my "to review" list for too long... :)

> --- David A. Wheeler


Attachment: breaktcc.c
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]