Re: [Tinycc-devel] autoconfiscation

[Rob Landley]

On Tuesday 28 August 2007 1:14:19 am Peter Lund wrote:
> >    How about not having that many tests?
>
> Certainly the option I would prefer.  I don't see tcc as having nearly
> as many external dependencies as my project had.

I don't know if this was one of Fabrice's design goals, but it's certainly one 
of mine.  Some day I'd like to get a self-bootstrapping system with just four 
packages:

  uClibc
  BusyBox (or ToyBox)
  linux
  tcc

I want to boot that under qemu and have it rebuild itself from source code, 
and boot _that_.

> > I actually think the _easy_ way to
> > handle this is to generate all cross compilers by default and then
> > have a
> > small shell script create a symlink to the one that produces output
> > for our
> > host platform (if any).
>
> I would like that :)

I'm kind of opinionated about how a compiler works.  I think it's no different 
from a docbook to pdf converter: it takes input and produces output.  If 
something like xml2 had extensive special cases and configuration for every 
host machine it ran on, it would be a deeply broken piece of software.

Yes, having different _targets_ is an interesting thing to configure, because 
the program is producing different output formats.  But that's unrelated to 
what host you run it on and NOT YOUR PROBLEM.  "On arm my xml2 produces html, 
and on PPC it produces pdf, and on mips it produces .PNG files!"  What's 
wrong with this picture?  Different behavior on different hosts is bad 
coding.  Cross compiling is NOT SPECIAL.

The machine your compiler runs on is none of your business, it's the problem 
of the host compiler you get built with, which is a separate piece of 
software and should already know everything interesting about your host 
platform.  (If you try to configure your software to work on a host OTHER 
than the one the compiler that's building you is producing an executable for, 
it won't work anyway.  It doesn't matter if it's a compiler or a web browser 
or what: it won't work.  So don't go there.)

If the output you produce happens to be an executable capable of running on 
the current platform, this is a happy coincidence.  But it's also not unique 
to a compiler: a sed invocation can produce a shell script.  Not brain 
surgery, and not worth jumping through extensive hoops at every level of the 
program to double-check.

</rant>

I still have to implement this, of course.  (Fabrice didn't fall far into the 
trap of thinking the host is important, but it's tangled in more than one 
place and I need to get around to cleaning it out...)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.