[qcc] qcc with external contributions removed

[Rob Landley]

On 02/21/2015 09:08 PM, Bruce Ewing wrote:
> OK, so I went through your list of patches, found their corresponding
> locations in the current code, and commented out all the code
> contributions that came from outside. (After reading your blog, it seems
> unlikely that relicensing permissions will be forthcoming.) Every time I
> did that, I annotated the change with the patch number, the
> contributor's name, and a little searchable pattern "OYOY" that I use
> often. I also attempted to work the diff backwards to replace the
> commented out code by whatever had been there previously -- or at least
> with some little kludge that should compile (also annotated).
> Considering the number of #ifdefs that I had to comment out, hopefully I
> commented out the right number of #endifs, too.
> 
> There were some changes to some text that ended up in your
> www/tiny-cc.doc file -- I assume that those are not a copyright problem?

I need to redo the documentation entirely, I expect. :)

> I also didn't bother commenting out anything that ended up in your new
> bash make scripts.

Those should be fresh code.

> elf.h has a FSF GPL on it, so that file needs a complete rewrite.

Indeed, although I note that scenes a faire probably applies anyway.

> tccpe.c has a 2005 copyright by grischka and an LGPL license on the
> whole file. So it's also toast (without permission).
> The file was created by patch 350, which is not on your list.

I'm not personally interested in windows output, although if somebody
else wants to maintain it...

Back when I was seriously doing my own tinycc fork, I set up mingw to
have a test environment:

  http://landley.net/notes-2008.html#20-01-2008

Probably not doing that again.

> tcccoff.c was partly created by TK, but this is the one file where I
> punted -- I could have tried to separate out the TK contributions from
> the Fabrice contributions and I didn't.
> (Because without the part contributed by TK, you don't have a coherent
> file left that can be compiled.)

My initial target is ELF. Especially since we should be able to create
elf->other format converters after the fact. ("should" and "can" may
differ, I still need to figure out what binflt is doing that requires
the linker to know about it before the elf is created. Only resolving
certain symbols, apparently. And musl needs -Bsymbolic-functions.)

> I did not comment out patches made to the gen.c files -- because, as I
> understand it, those are precisely the files that will be replaced with
> the qemu code.

Eventually, yes. But I don't know how long that'll take.

> Patches 306 and 308 were gen files only.
> None of the code in patch 348 exists anymore.
> 
> 
> Beyond all that, it seems this code has been descending into #ifdef
> hell, as defined by the "#ifdefs are dangerous" paper that you linked to
> in your blog. So it sure looks to me like a major rewrite is due.

Very much so.

My general plan of attack was to try to break it into cpp, cc, as, and
ld code. (preprocessor, compiler, assembler, linker. I'm aware the
compiler produces machine language not assembly, I'm thinking of that as
a .c->.o file converter.)

> I am going to proceed to do a major rewrite of it in any case, for
> myself. I'll show you how my version looks in a month or two, and you
> can decide if you hate it or not. Maybe we can compromise, or maybe
> it'll just be another fork and you won't have to deal with me again. ;-)

I'm certainly interested in seeing what you do, I'm just a touch
overwhelmed on multiple fronts at the moment.

  http://landley.net/notes-2015.html#21-02-2015

Rob