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

[Rob Landley]

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

> And
> 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
> now.

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
> http://repo.or.cz/w/tinycc.git.

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):
http://www.mail-archive.com/address@hidden/msg01141.html
http://landley.net/hg/tinycc/rev/510
http://landley.net/hg/tinycc/rev/511

> 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:
http://landley.net/notes-2007.html#28-12-2007

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:
http://landley.net/hg/tinycc/rev/545

Me moving code generators into per-target subdirectories:
http://landley.net/hg/tinycc/rev/449
http://landley.net/hg/tinycc/rev/509

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:
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/412

Here's me breaking out tcc.h in the first place:
http://landley.net/hg/tinycc/rev/426

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):
http://landley.net/notes-2006.html#14-10-2006

A few random examples of me poking at corner cases of C99 features (which I 
usually found trying to build real packages):
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/477
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/468
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/476
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/535
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/417
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/487

Me adding a link to the c99 spec to my copy of the documentation:
http://landley.net/hg/hgwebdir.cgi/tinycc/rev/495

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:
http://www.mail-archive.com/address@hidden/msg00487.html

Here again (in more detail) in 2007:
http://www.mail-archive.com/address@hidden/msg01123.html

It seems to have come up most recently september of last year:
http://www.mail-archive.com/address@hidden/msg01861.html

Here's from the linux kernel mailing list back in 2006:
http://lkml.indiana.edu/hypermail/linux/kernel/0603.3/2174.html

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:
http://www.mail-archive.com/address@hidden/msg00694.html

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

Rob