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

[Rob Landley]

On Thursday 12 March 2009 16:20:28 Marc Andre Tanner wrote:
> Hi,
>
> On Wed, Mar 11, 2009 at 06:07:51PM -0500, Rob Landley wrote:
> > It's been 6 months, I thought I'd ask.
> >
> > People still occasionally email me links to a tcc git mirror (not sure
> > why), and I reply that mirrors are nice, I even used to run one, but that
> > any project that still cuts its releases from a CVS repository in 2009
> > simply isn't _interesting_.  (Which is a pity, now that the gcc
> > developers are apparently rewriting their C front end in C++.  Oh well.)
>
> I guess the CVS is unfortunately still around, but the development is
> mostly done in various git repositories on repo.or.cz. Therefore I propose
> to push the main git repository to Savannah and depreciate the CVS.
>
> grischka and Daniel you are the ones who actually committed code during the
> last few months, what do you think?

Grischka put out the last release, therefore Grisckha is the maintainer.

Look, if you guys wanted to get serious on this project, what you'd need to do 
is grab QEMU's Tiny Code Generator and glue it onto the back end of tcc.  
(Start by reading the attached file, which is tcg/README in the qemu source, 
the code is licensed under a BSD no advertising clause variant.)

Using TCC as the code generator for tcc means A) you now support just about 
every interesting target type, B) a development community ten times the size 
of yours is constantly enhancing your code generator.  This project has proven 
conclusively that it hasn't got the manpower or expertise to support a dozen 
different hardware targets, but you don't HAVE to if you can make use of a 
project that already does.

Then you need to regression test the hell out of the code, make it work with 
uClibc as well as glibc (I did that back when I had a fork, static linking was 
surprisingly tricky), and try to build real packages with it.  Building 
busybox means you need simple dead code elimination but that's not actually 
_that_ hard (tcc already has constant propagation, just output each new curly 
bracket context into a temporary buffer if you're not going to use it).  To 
build the Linux kernel you also need the variable array thing, and a few other 
things.  (I had a list, back when I cared, before I got SICK of the stupid CVS 
archive hanging over my head.)

You should also make tcc do the "one binary multiple commands" thing like 
busybox; if the name ends in "cc" it's a compiler, the name ends in "ld" it's 
a linker, the name ends in "as" it's an assembler, and so on.  Become a proper 
binutils replacement as well as gcc.  (This part is _easy_.  You already need 
the "-Wl,option" thing to support all sorts of package builds, so the logical 
way to implement that is to actually have a function that processes linker 
commands for "ld" mode, and have the "cc" command parser hand off to it as 
necessary.  The hard part is "as" support, but you need that for inline 
assembly anyway.)

For reference, binutils provides: size, objdump, ar, strings, ranlib, objcopy, 
addr2line, readelf, nm, strip, c++filt, as, gprof, and ld.  I note that 
busybox already has strings and half an ar implementation.  Strip, nm, size, 
readelf, and objcopy are pretty straightforward elf support, which tcc already 
has most of the code for.  Objdump needs assembly dump support, I've totally 
forgotten what ranlib does, never used gprof, c++filt is only needed for 
c++...  It's really not that hard.  (Once they're in, it might be interesting 
to try building gcc against tcc's binutils replacements and see if it works.  
It's got an autodetecty thing for "non-gnu ld", and somebody wrote gold from 
scratch recently..)

Also, it would be nice to clean up the path logic, so you can explicitly 
specify the paths (and get it to dump them at runtime) and so the compiler's 
trivially relocatable.  And not with some stupid "sysroot" thing, I've already 
got a gcc wrapper that autodetects the location of the binary and grabs the 
other files relative to that: 
http://impactlinux.com/hg/hgwebdir.cgi/firmware/file/tip/sources/toys/ccwrap.c
An easy thing to do would be to make it follow symlinks until it finds an 
actual executable file, and then calculate #include and library paths from 
that, so you can extract the tcc tarball anywhere you want but drop a tcc 
symlink into an existing $PATH directory...

Sigh.  It's painful to watch the wasted potential of this project, but as long 
as the CVS archive is "official" that potential will continue to be wasted.

I'll stop now.  Let me know when (if) the CVS archive dies.

Rob

README
Description: Text Data