Re: [Tinycc-devel] [PATCH 5/5] Fix gv for long longs

[Rob Landley]

On Saturday 06 September 2008 23:39:16 KHMan wrote:
> Of course I agree with all of your (Rob's) arguments, and I'm sure
> most others as well. Don't need to keep repeating arguments I
> already agree with. I just think this project should deal with
> manpower first, and I'm RCS-neutral.

The thing is, I'm not.

The repeated resurfacing of CVS has driven me away from this project several 
times now, for at least 3 months each time.  Trying to deal with manpower 
before brain-damaged source control is focusing on effect and ignoring cause.

> Okay then, you know, we're going around in circles. :-) This is
> exactly like a past discussion that ended up with me setting up
> the hg repository.

Yeah, I remember that.  I set one up, you set one up, neither were "official" 
and neither stopped people from checking more things into CVS and cutting 
releases from them.

And hey, if that's how tcc development happens, I'm happy to get out of its 
way.

> So I did try to get this tcc onto a modern 
> distributed RCS, and then managed to get Detlef to take over, but
> no commits in the past 7 months or so. Anyone care to continue
> that? So that's one data point. It says we need muscle.
>
> No muscle, no results. Need'um reliable muscle first, else
> everything is stuck. Even the scenario where you (Rob) kindly send
> patches over under LGPLv2 requires muscle plus a distributed RCS.

Not really.  I could post 'em to the list at patch files.  What I can't do is 
read other people's patches that _weren't_ posted to the list, but instead 
went directly into CVS.

It's not a question of setting up a new source control system.  That's 
trivial.  It's a question of KILLING OFF THE CVS ARCHIVE, which will never 
happen.

> I was just trying (very carefully, knowing you are around, but
> obviously not carefully enough) to point out to the list that
> without reliable muscle, nothing is going to move.

There's no muscle _on_this_list_, because there's no interest in checking crap 
into the old CVS except on Grischka's part.

Back before I gave up on my fork (for the second time), I put enough "muscle" 
into it that wikipedia mentioned it, tinycc.org linked to it, there was even 
an Ubuntu launchpad entry about potentially switching to it:

  https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/201627

Heck, I hosted a compiler BOF at this year's OLS where I talked about it:
 
http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg

I didn't give up on it due to lack of "muscle", I gave up because no matter 
what I do, the old zombie CVS continues to lurch forward, and life's too 
short for me to to feel guilty about not fishing around in that toilet to see 
what patches I might be missing.

Yes, my time is spread between a half-dozen projects, and I'd rather not be 
maintainer of a project I'm the only developer on.  But what's sillier is 
racing to stay ahead of a _dead_project_.

Most of what Grischka checks in to CVS is for the windows platform, about 
which I don't much care and can't easily test.  (Yeah, I set up a wine based 
test environment six months ago.  Now that I've upgraded to Kubuntu 8.04 I'd 
have to reinstall it, and I just haven't bothered.)

Nobody but me seems to be working on an x86-64 target, or even an x86-64 
_host_.  You are aware that 32 bit x86 hardware is no longer being 
_manufactured_ outside of the embedded space?  Everything that's shipped this 
year has been 64 bit.  How long will Ubuntu continue to put out a 32 bit 
Linux distro, do you think?  3 years?  5?  Since your project doesn't run on 
x86-64 you probably haven't noticed that if you use "-run" from a 64 bit 
version of tinycc it segfaults, because it jumps to a function pointer full 
of 32 bit code while in 64 bit mode.  That requires changes to the build 
system so "-run" is only enabled for a fully native compiler, which is a 
trivial configuration test.  Except I've completely rewritten my build 
system, it looks nothing like yours, so any work I do there brings the two 
projects further away.  My build system lets you individually specify all six 
compiler paths; yours does not.

Nobody but me seems to care about making the existing targets cross compile to 
each other.  (Tried building running the x86 code generator on arm?  
Segfault, unaligned access...)

And yet people keep asking _me_ about the 0.9.24 release, and why it has such 
and such bug they thought I'd fixed a year ago.

> So to keep my message simple -- what we need is action, and I
> think those who can take action gets to decide.

I spent two years working on the codebase.  I collected other people's code, I 
came up with my own changes, I debugged things, I added tests, I did actual 
work.  Not useless talk like this email message, _work_.

My work _before_ I changed the license got cherry-picked and flushed into the 
CVS, and wound up in the 0.9.24 release.  And I'm happy that tcc got out a 
new release.  But it does mean that my fork is dead, because to continue to 
work on it I'd have to go over cvs to see what changed, and that simply won't 
happen.  Your version is still missing rather a lot of work I've done.  But I 
can't change it, and nobody here wants to, so I'll stop bothering you now.

> Forget I ever 
> mentioned CVS. We're beggars here, the thingy is mostly in deep
> freeze, and in my very humble, personal opinion, I think I would
> accept a bowl of plain rice instead of holding out and starve in
> hope of a gourmet meal. I also think opinions like mine are very
> cheap, thus I fervently hope for someone to step up to the plate.

I don't want to fight what's left of the tcc community.  Daniel's doing 
important work on arm that I can't do.  Grischka knows more about the windows 
target than I'll ever care to.  But my next major tinycc todo item was to 
busyboxify the thing so it works like "ld" when you call it as "ld".  This 
involves merging my gcc command line parsing wrapper script logic so it's 
even more of a drop-in replacement for gcc, and can be used as the 
preprocessor part of "distcc" combined with gcc on the daemons to generate 
the .o files, and then tinycc to link them.  That's a useful goal, easy to 
test, and it helps out my Firmware Linux project by making the parts that run 
inside the emulator work faster, and splitting out the bits that should work 
everywhere right now (no reason the preprocessor can't do a "tcc -E" on a 
mips or powerpc host) from the bits that need serious additional work (ala an 
x86-64 code generator).

But for me to do that would be based on the work I've already done to break 
the options parsing logic out into a seperate file, and rename/move the i386 
target into an i386 sudirectory and so on.  My code is pretty far from tcc 
0.9.24, and this would move it farther.

Daniel's work isn't based on my fork.  Nobody else's is.  Instead, what work 
they do is based on the CVS version.  And people continue to test the cvs 
version.  When a bug report comes in (like 
https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/1898 or 
https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/71059) does it occur in my 
fork, or did I already fix it?  When something like 
http://lists.gnu.org/archive/html/tinycc-devel/2008-08/msg00009.html happens, 
what do I do?  I don't use that feature and they don't use my version, I 
probably have that bug but is it worth fixing in a fork NOBODY ELSE WILL EVER 
USE?

These days even stuff like 
http://lists.gnu.org/archive/html/tinycc-devel/2008-08/msg00007.html with a 
patch sitting there, all I do is mark it "todo".  I did some fairly extensive 
renames ala http://landley.net/hg/tinycc/rev/574 and patches to the old code 
may or may not be easy to figure out where to apply to my fork.

But the people checking stuff into the old CVS seem quite happy to continue to 
do so, and nothing _I_ do is going to discourage them.  It seems quite the 
opposite: even after I changed the license to discourage the cvs, after I 
added "-v -v -v" verbose debugging info to my version, the cvs version got 
its own (somewhat incompatible) -v -v -v.  I stopped working on my fork four 
months ago, and coincidentally the CVS has not seen a checkin for the past 4 
months.  But I guarantee you that if I start checking stuff into my tree 
again, "oh, look, more checkins to CVS".  It's happened how many times now?

Maybe I'm just imagining that there's a weird cycle going on where the CVS 
dying down encourages me to work on my version, and me working on my version 
encourages the CVS to start up again and make unpleasant forensic work for me 
to do if I don't want to feel like I'm doing a half-assed job of making the 
best tinycc version I know how to (thus totally discouraging me from working 
on my fork again until CVS goes silent for long enough that I'm sure it's 
dead _this_ time).

But even if it's coincidence, I'm not working on tinycc at all anymore (my 
fork, somebody else's fork, whatever) while the darn CVS repository still 
exists.  Even if I'm imagining it, it still bothers me, and it still makes 
unpleasant work for me to see what bug they think they're fixing and whether 
or not it applies to my version.  That CVS repository hung over my head for 
two years, and that's long enough.  It's no fun anymore.

When I stopped regularly posting on this list, and changed the license of my 
project, that encouraged the existing developers here into enough of a spurt 
of activity to put out a 0.9.24 release.  Maybe this will encourage another 
such spurt.  This difference this time is, I don't really care.  I don't 
believe development done in the CVS archive in savannah will never produce a 
compiler capable of building an x86-64 version of a current linux kernel.  It 
will continue to lurch along until 32 bit hardware becomes obsolete (just 
like Windows XP), but so what?  Maybe after that we'll all be using Apples 
(and the mach-o backend I've wanted to work on is even farther down the todo 
list of "things nobody else on this project cares about").

I cannot make CVS go away.  I've spent two years trying to work around CVS.  
I've increasingly distanced myself from it, but it follows me.  This is not a 
new issue, here it is cropping up a year ago:

http://lists.gnu.org/archive/html/tinycc-devel/2007-05/msg00107.html
http://lists.gnu.org/archive/html/tinycc-devel/2007-05/msg00075.html

Here it is cropping up February 2007:
http://lists.gnu.org/archive/html/tinycc-devel/2007-02/msg00028.html

Here I am back in October 2006 trying to shut down my mercurial tree, handing 
Fabrice a tarball of all the patches I'd collected:
http://lists.gnu.org/archive/html/tinycc-devel/2006-10/msg00122.html

Why?  Because if he was going to check stuff into CVS, I wasn't going to track 
it.  I can't track CVS, and never could.  I was happy to step back and become 
just another user.  (Still would be if the project actually did what I 
wanted, which it doesn't.)

Before I ever _did_ a fork, we were arguing about source control:
http://lists.gnu.org/archive/html/tinycc-devel/2006-09/msg00049.html

And I described my initial efforts to create a mercurial mirror I could actual 
develop against as "fighting with CVS":
http://lists.gnu.org/archive/html/tinycc-devel/2006-10/msg00042.html

I spent two years trying to overcome the CVS repository, but the CVS 
repository is still there, and like a nuclear waste disposal site it's likely 
to continue to be there, festering, forever.  Two years is about my limit for 
playing sisyphos.  I can't do tcc development without having to deal with 
CVS, thus I can't do tcc development.

Rob