[Top][All Lists]

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

Re: [Tinycc-devel] Is the CVS repository dead yet?

From: grischka
Subject: Re: [Tinycc-devel] Is the CVS repository dead yet?
Date: Sat, 21 Mar 2009 15:33:58 +0100

Dear Rob, I think you made sufficently clear by now that you would ideally like to see a TinyCC that is official and has all the features of your fork at the same time.

Which is only natural seen all your work and everybody can feel your pain and 
just there is no simple or fast solution to it now.

Fact is that there was a phase where we analyzed your fork and ripped as much as we were able to understand. This phase is over now and TinyCC is moving on.

If you feel that you have more valuable features there or elsewhere that you want to contribute to "offficial" TinyCC then probably the only way is to advertise them once again patiently one by one here on the list. See the Changelog file for a list of hg-rev's that have been included.

Then, not that I had any sympathy for your absurd fight against obsolete VCS's in context of this little project, but solely to my own convenience I'd suggest that:

- We make the 0.9.25 release soon, introducing the new x86-64 target contributed by Shinichiro Hamaji. - And let 0.9.25 be the last code point in CVS and switch to GIT at Savannah immediately after the release. This GIT will (hopefully) have the same commit-ids as the one at http://repo.or.cz/w/tinycc.git so until then working with that should
  be just as fine for EVERYBODY.

I'm away currently so it can take some weeks until I touch that or anything else with this project at all. However in the spirit of "distributed development" I appreciate
very much what people do, in between and anyway.

--- grischka

P.S:  To grep for words (even single letter words) use "grep -w ..."

----- Original Message ----- From: "Rob Landley" <address@hidden>
To: <address@hidden>
Cc: "grischka" <address@hidden>; "Joshua Phillips" <address@hidden>
Sent: Saturday, March 21, 2009 6:54 AM
Subject: Re: [Tinycc-devel] Is the CVS repository dead yet?

On Friday 20 March 2009 13:32:29 grischka wrote:
----- Original Message -----
From: "Rob Landley" <address@hidden>
To: "Joshua Phillips" <address@hidden>
Cc: <address@hidden>
Sent: Friday, March 20, 2009 5:44 PM
Subject: Re: [Tinycc-devel] Is the CVS repository dead yet?

> On Thursday 19 March 2009 10:30:53 Joshua Phillips wrote:
>> Rob,
>> I feel your pain :(
>> I have had a look at the tcc git repository and it has many duplicated
>> commits (rebased?) and is a complete and utter mess.

I don't think it is an "utter mess", in that sense.  I mean, if occasional
duplicate commits make someone feel bad they can just delete them from
their personal repo.

> Similarly, I implemented -v -v -v to let you see what the compiler's
> search paths: the #include search path, and the linker search path, and
> what symbols the linker found while searching.
> http://landley.net/hg/tinycc/rev/d72f42753974
> When tcc copied it, did they realize _why_ I did it?

What makes you think other people don't know what they are doing?

"Not knowing what they're doing" and "partially copying a feature without realizing why the feature was added" are two different things. (Mostly I just disagree with the design decisions.)

anyway why should other people have had the same "reason why"? After all
your "reason why" must be seen in the context of a fork that is dead by

Because I chose to stop working on it, yes.

> By the way, did they ever come up with a correct fix to this one?  I
> can't get a log of changesets to see for myself:

If not you then everyone else at least can at

Forgive me for not realizing that a repository that hasn't been updated for 3 and 1/2 months was the "active" one. I've downloaded it and am reading through it.

> Yes, I occasionally broke stuff and had to fix it, but you can't grep for
> anything in tcc!  Single character global variable/function names are a
> BAD THING.  It needs to be FIXED.  I was doing that, back before the
> 0.9.24 release rendered anything that _wasn't_ based off the 0.9.24
> release (and never would be) obsolete and unofficial.

Actually everything essential from your fork went into the last release,

Ok, one random example. The tcc ./configure still attempts to identify the host processor, and arbitrarily dies if you attempt to build on an armv5l or sh4 host. This is despite the fact that the host compiler #defines preprocessor variables for the target so at build time the C code can easily test what target you're building for without having to grovel around for it. So this is a) unnecessary, b) wrong. (And despite caring so much about what host you're building on, you still enable -run in cross compilers.)

Don't get me started on the path logic rant (although that's old news here, but still not addressed):

except the "array [restrict]" fix as recently mentionned by someone on that
list. You are welcome to push that on our "mob" branch, if you want to.

Not if you're going to push it from there into CVS.

And when I left off the array stuff was in progress. I forget what specifically was pending. (I remember it was leading up to implementing resizeable arrays properly with both sizeof() and for(;;) loops not leaking 'em, but it was a multi-step process and it's been a year.)

Any formal changes however were recjected.  There is absolutely no need to
change variable names at this time.

So single letter variable and function names which you can't actually grep for aren't considered a bad thing, then? The current source code does not need to be cleaned up or refactored, in your opinion?

I blogged extensively about the worked I was doing, and the reasons for it:

I didn't post it _here_ because A) the cvs archive was still "official", B) this list's spam filter blocked me for a while in early 2007 and I fell out of the habit: http://landley.net/notes-2007.html#11-01-2007

As for a different file structure with
subdirs, well, that may come, eventually.

Not at this rate.

I just wanted to have the 0.9.24
release with the same file structure as before because like that it is
easier to see the real changes.  That's all.

The 0.9.24 release was in april of 2008.  That was just about a year ago now.

Anyway, of course we appreciate and thank you for the work you did.  It
is just that you work was filtered and reviewed one more time. I think that
is a good thing after all.

I'm all for the work being reviewed and filtered. I'll happily engage in design discussions to try to explain my thinking. It was the "CVS is the only way" thing.

> Let alone breaking out option parsing into a separate file, moving the
> code generators into per-target subdirectories, creating tcc.h in the
> first place... Nobody's doing infrastructure work on this thing. > Nobody's trying to build real packages with it and fixing the bugs. > Nobody's filling in the missing C99 features like variable sized arrays. > Nobody's worried about powerpc or mips support, or trying to come up with
> a libtcc.a for arm.  (Lots of code refactoring to make multiple backends
> easy to do systematically. Notice how I was doing lots of code
> refactoring?)

Well, you didn't anything of that either.

Me breaking option parsing into a separate file:

Me moving code generators into per-target subdirectories:

And while we're at it, here's me moving the includes into a subdirectory too, way back when, because having them at the root level was messy and complicated install. Simple, obvious cleanup, no? Except that 2 years later, it's still not in the cvs version, presumably because moving files under cvs loses all history:

Here's me breaking out tcc.h in the first place:

Poking at building real packages with tcc as pretty much the first thing I ever did with it (never really stopped, sort of the point of having a compiler, just got a long list of "known broken" todo items I knew I needed to fix):

A few random examples of me poking at corner cases of C99 features (which I usually found trying to build real packages):

Me adding a link to the c99 spec to my copy of the documentation:

A few days ago I suggested on this list how to get support for other targets (leverage TCG from qemu). I myself was working on x86_64, although I'm glad Shinichiro beat me to it, and would be happy to test his version.

Would you like LOTS AND LOTS of examples of me doing code refactoring? It's at least 1/3 of the commits I made to my archive...

You did many things that you said
is (or at least looks to me like) "preparation work".  However preparation
for what?

Here's me explaining it on this list in 2006:

Here again (in more detail) in 2007:

It seems to have come up most recently september of last year:

Here's from the linux kernel mailing list back in 2006:

That's not counting numerous mentions on my blog and my website. (My fork also had its own mailing list for a while, but I took it down and the archive didn't survive the last server upgrade.)

I've always wanted to make tinycc a general purpose replacement for both gcc and binutils. (Maybe not producing particularly optimized output, but capable of building all the thousands of packages in a full gentoo or debian distro.) Remember how I worked on turning busybox into a replacement for all the gnu command line stuff?

You are the only one to know and you never got there.

Yes, because the darn CVS kept hanging over my head, so I kept stopping work on my fork because of it. (As I said repeatedly at the time.)

So either
your preparation work was wrong or the goal it was preparing for was the
wrong one or maybe came at the wrong time.  You cannot expect us to make
the same mistake.

No. I stopped work because of the CVS repository, and I won't publish another line of TCC code until the CVS repository dies.

Quoting from this November 22, 2006 message:

The accept-from-stdin thing was just a request for feature, I didn't see
anybody come up with a patch.  I haven't been particularly active since
Fabrice rendered my tree moot last month, but I've still been reading the
list and haven't seen it wander by...

Yes, that's right, in november 2006 I'd already stopped work on my fork because of the CVS tree.

The pattern of "I do work, CVS advances but not based on my tree, I stop doing work, CVS dies" dates back to the beginning of my fork. I _never_ put anything into CVS, I could never see what was _in_ CVS in any coherent manner (I got tailor to work to covert the archive to mercurial _once_, and then an ubuntu version upgrade broke the cvs library tailor depended on (introducing an 8 bit rounding error) and nobody ever fixed it because CVS is so deeply obsolete. I couldn't even re-covert cvs to make a new mercurial archive, I couldn't get a changelog, and could only match up patches that touched more than one file _by_hand_. I grew to HATE the cvs repository, and I still do.)

> When I started my fork, tcc was already essentially dead.  The
> _existence_ of my fork seemed to revitalize it.  I'd work on my fork,
> work on the rest of tcc would pick up again.  I'd stop work on my fork to
> get out of its way (the first time sending a tarball of accumulated
> patches to Fabrice), and tcc would grind to a halt again.  So I'd start
> work over in mercurial again, and CVS would start moving again.  I did
> this what, five times?  Got sick of it.

But why? You worked on TinyCC and your work finally went into the main
codebase. Sure, not everything, but the good stuff did.

You just demonstrated above that you don't actually know what I did, or why I was doing it, but you're sure none of the bits you don't know about could possibly be of value.

I admit that I didn't post them here and try to push them into CVS, because I didn't WANT them to go into CVS. I wanted the CVS to _die_ and be replaced by a source control system that wasn't horrendously incompetent. The entire reason I changed the license on my fork was to _prevent_ my code from keeping the zombie CVS repository alive one second longer than otherwise. That might have been a _hint_ about how I felt.

What did you expect?

I expected that I wouldn't have to keep trying to fish bugfixes and windows target support changes out of the toilet of CVS. Things that were never posted to the mailing list, and which the ONLY way I could see what the changes were (or whether they were even interesting, or redundant vs what I was doing) was to look at every individual file in CVS because the command line tools couldn't give me a list of changesets and the web repository viewer was utterly horrible.

I didn't expect that my version and the version releases were cut from would continue to diverge so that figuring out whether changes from one was even relevant to the other became more and more of an issue.

If by the time you went too far with cluttering your fork with unneeded
formal changes you cannot complain now that you have problems with
backporting new contributions from the main base to your fork.

I had no problem backporting new contributions to my fork. Mostly I didn't _need_ to, the vast majority of it was noise. But it had the tinycc.org website, which came up first in google and had its releases covered by Linux Weekly News for historical reasons, and thus it's the version that newbies usually picked up (and where they sent their bug reports).

My problem was never ability to make progress, my problem was "why am I doing this when the CVS version will always be 'official'". When I discontinued my version, yours didn't even _build_ on an x86_64 host.

I left because of the CVS repository. I've said this many, many times now. Not because of some technical defect with my tree, but because of social engineering issues having to do with open source development limiting my potential to attract new developers while an external factor continued to occlude my project, and my own severe discomfort with the conditions required for participating in that external process.

I realize you don't understand my reasons, but please don't make up nonexistent technical deficiencies as an alternate explanation. I keep getting people asking me to continue my tree. Still. A year later. That is not a sign of technical deficiencies.


reply via email to

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