While I am generally in favor of this idea (and I did get the first
miniparrots to work, pretty much as proof of concept), I do think it's
likely to be rather challenging (and interesting):
Remember, _pure_ C89 provides only these headers:
<assert.h> <complex.h> <ctype.h>
<errno.h> <fenv.h> <float.h>
<inttypes.h> <iso646.h> <limits.h>
<locale.h> <math.h> <setjmp.h>
<signal.h> <stdarg.h> <stdbool.h>
<stddef.h> <stdio.h> <stdlib.h>
<string.h> <tgmath.h> <time.h>
<wchar.h> <wctype.h>
This leaves out a number of things that one would really like to have
to do system probing, most notably:
- file info (stat, fstat)
- executing programs in any kind of sophisticated way (fork/exec, pipes)
My only real point is that, while I think pure c89 is a nice goal, in
practice we will need to relax this just a bit, to include at the very
least, things like unistd and bits of posix that are likely to be
everywhere. Should be interesting.
Probably isn't going to really gain momentum until we get some of the
build system written in something that compiles down to run on parrot..
How's that perl 6 compiler coming? ;-)
--Josh
At 18:20 on 09/07/2004 EDT, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This argument's old. Very old, so it may be unfamiliar to many
> people. The subject generates enough heat that I don't want to go
> there again.
>
> We are not using autoconf. Period.
>
> Parrot's build process, when shipped will be:
>
> *) Person building runs platform-specific script
> *) Script builds miniparrot, which assumes ANSI C89 functionality only
> *) Miniparrot runs provided configure program, which is in bytecode
> *) Configure probes environment
> *) Full parrot is built
> *) Full parrot is then invoked to complete the build process, which
> is driven by a program written in a parrot language and provided as
> bytecode
>
>
> --
> Dan
>
> --------------------------------------it's like this-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
