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