Re: [Tinycc-devel] Allow configuration of tcc libraries search path

[Rob Landley]

On 09/30/2011 10:25 AM, Kirill Smelkov wrote:
>>> I have it as git branch btw. If anyone is interested I could push
>>> it on repo.or.cz.
>>
>> I thought your current maintainer policy was zero editorial control,
>> just let random strangers form a slush pile in the mob branch and then
>> ship it?  (I can't say I've been reading the list very closely.)
>>
>> It's a little disheartening to see issues I fixed over three years ago
>> come up over and over again.  If I recall, you refused to port things
>> you either "didn't understand" or didn't see a need for (such as
>> refactoring the code so it wasn't one big tcc.c without even a tcc.h)
>> from my tree the last time I gave up and waited for you guys to just
>> stop it.
>>
>> I put a lot of work into my version, but Fabrice wouldn't hand it the
>> project to anybody who wanted to move the code out of the gnu.org CVS
>> repository, and Linux Weekly News covered releases that went up on
>> tinycc.org, even back when the bulk of the changes in them ported from
>> my version.  I wouldn't mind so much if you didn't REFUSE TO TAKE
>> OBVIOUS THINGS that you're now finding a need for all these years later.
>>
>> Sigh.  I'm going to go back to ignoring this list now.  I should go
>> catch up on the pcc and llvm lists...
>>
>> Rob
> 
> 
> Rob, thanks for the links and for sharing. Are you in principle ok to
> relicense your changes back from GPL to LGPL so that they could be
> included one way or another into tcc?

Years ago, in my repo, I significantly refactored the code to do things
like put declarations in headers, put architecture-specific code in
subdirectories with consistent names, break out the command line option
parsing into a separate "options.c", and so on.  There were a functions
named g() and o() which were IMPOSSIBLE to grep for (leftovers from its
heritage in the obfuscated c code contest, I guess), which I laboriously
replaced with sane names.  I started grouping random global variables
into structures, I was working on splitting the preprocessor, compiler,
and linker code into three files... Half of what I did was code CLEANUP.

Grischka had no interest in any of that.  Instead he cherry picked a few
commits he understood:

  http://lists.gnu.org/archive/html/tinycc-devel/2007-12/msg00040.html

And then told me that I had to abandon my cleanup work and start over on
his tree, and explain everything to his satisfaction (as a Windows guy)
before it could go in.  I'm still kind of pissed about it:

  http://landley.net/code/tinycc

I.E. his current policy of "go ahead and commit anything you like, I
don't care" isn't what he used to do.  It's an overraction in the other
direction.

For the patches in question, I'm pretty sure he _specifically_ told me
that he _didn't_ want colon separated search paths.  (Even though I
broke down and made it configurable so it could be semicolon instead for
his windows sensibilities.)

My initial complaint was CVS made it hard for me to work, true:

  http://lists.gnu.org/archive/html/tinycc-devel/2008-09/msg00013.html

But I changed the license because the zombie CVS tree was following me,
and I didn't want to encourage it:

  http://lists.gnu.org/archive/html/tinycc-devel/2008-09/msg00027.html

But these days, my complaint is that I have no confidence whatsoever in
tinycc's maintainership.  It has the tinycc.org domain, and Fabrice
handed over the project, so it is the official final resting place of
tcc.  But it's still stagnant, because Fabrice put a Windows developer
in charge of the project, one who apparently does not understand open
source development in the slightest. He's putting out a windows-only
version of tcc as far as I can tell, one which will never build an
unmodified Linux kernel (has made zero progress on this front in the
past _THREE_YEARS_), thus it cannot ever act as (even an infereior) gcc
replacement.

Thus I have no interest in it.  I check back every few months to see if
it's _died_ yet, but it's really mostly curiosity at this point.

Someday if I get back to this topic, I want to glue either sparse or the
tcc front end to qemu's tcg back end and produce a new compiler that A)
supports all the targets qemu does, B) can build linux and busybox and
uClibc and itself (thus providing a self-bootstrapping system; I'd
upgrade busybox to have missing bits like "make").

See the attached files for some todo items on that front.  But according
to the dates on those files, I last touched them in May 2009, so this
isn't exactly a priority for me.  Tinycc isn't dead yet, and there's
plenty of _other_ interesting stuff like the LLVM backend for Sparse:

  http://lwn.net/Articles/456709/

> For us, tinycc users, it's a pity to see this issue being stagnated over
> and over again. The CVS is de-facto gone - if it was it, now there is no
> point to block your changes being merged!

Tinycc has been stagnant since Fabrice left in 2005.  It saw surges of
effort from me, from David Wheeler's trusting trust paper, the people
who did the arm and x86-64 ports, and grischka's work on windows stuff
(and on getting gcc to build under it)... but it never added _up_ to
anything.  I started by collecting together various out of tree patches,
and then poured hundreds of hours of my own effort into it, but nobody
wanted to build on my work becaue it wasn't "official".

Instead a windows developer turned it into a windows-only project, and
he has such a poor understanding of open source development that he
doesn't even do code review or control access to the repository.

Do you have any idea how WRONG that is?  Alan Cox once told me "A
maintainer's job is to say no".  And he's right: they're like the editor
of a magazine, going through the slush pile to find the best bits,
polish them up, stich them into a coherent next issue, publish, and
repeat.  This is not a new task, this is basic editorial judgement that
people have been doing since Gutenberg invented the printing press.

Publishing the raw slush pile is NOT INTERESTING.  Fighting off
Sturgeon's Law is what editors _do_.  It doesn't matter if we're talking
about the four levels of Linux developers (developer, maintainer,
lieutenant, architect) bouncing back patches with comments, or
Cannonical leaving 98% of sourceforge OFF their install CD, or sites
like Slashdot and Fark publishing a tiny number of headlines from the
thousands they get each day, or Google giving you a page of ten most
interesting hits from an internet approaching a trillion pages of spam,
porn, and emo blogs with cat pictures.

Grischka has not set direction for the project, let alone goals.
Where's the list of problems that need to be solved?  Where's the "and
now we build package X" announcements?  Where's the RELEASE SCHEDULE?

  http://video.google.com/videoplay?docid=-5503858974016723264

This project is still unmaintained, it's just unmaintained by Grischka.
 The last release on tinycc.org was TWO AND A HALF YEARS AGO.  Even
uClibc never got quite that bad.

> Sometimes people need time to de-cvs'ify themselves and adopt good
> distributed vcs practices.  I agree about somewhat funny current mob
> rules, but it would be a very pity again if that would be a blocker for
> cooperation.

I do not trust Grischka's technical judgement, his committment to the
project (I put way more time into my fork than he's put into the
official version), his leadership abilities, or his organizational skills.

I spent three years of my life improving this project (not just coding
but documentation and testing and design and so on), and the result was
esentially discarded at the whim of somebody who DIDN'T UNDERSTAND WHAT
I WAS DOING.  The fact the rest of you are now finally realizing that
some of the problems I already solved years ago were, in fact, real
issues, is mildly amusing to me in a morbid way.

If you have competent developers on this lsit you don't NEED my patches,
you can figure out how to do it from the _idea_ in a couple hours.  If
you need more details, I discussed the general idea somewhat at length
at the OLS compiler BOF in 2008:


http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg

I doubt my patches will remotely apply to the git codebase anyway, I
changed a _lot_.

Rob

todo.txt
Description: Text document

todo2.txt
Description: Text document