Re: TODO

[Bruce Korb]

Hi, Guys,

> >> 5. Think about speed, compile mode needs to be as fast as possible,
> >> can it be faster than it is?

> My impression is that fork() is half the problem here.

_Only_ half?  :-)  It's fun thinking about what Cygwin goes through
to make fork() work on windows...

> Would making some
> sort of uber-shell, with more builtins (say a sed command for example) help
> out?

I would think "uber-shell" would be a shell to end all shells.
I believe we are looking at a mini-shell that might have a few
extensions specifcally to make libtool/autoconf easier to work with.

> ... and which could be bytecompiled.

> Also Bruce Korb had a play with a compilable libtool in C generated by
> his autogen project.  Things in Libtool have moved along enough that it
> would probably be easier to take this approach rather than my convoluted
> idea.

The real problem with my approach was that I was doing it alone
and real life intervenes ... I got far enough along to show that
it can be gotten to work, but not far enough along to have any
noticable advantage.

> I am certainly not against the idea of translating ltmain.m4sh into C, we
> just need to freeze changes to ltmain while it is underway.  I think we can
> tackle it in stages:
> 
>    1. call the existing ltmain.m4sh in a C wrapper
>    2. convert the compile and runtime infrastructure to compensate
>    3. pick a small mode
>    4. convert it to C from the top down
>    5. pick another mode and repeat until done

More or less.  There are a number of fun little gotcha'a along the way,
but nothing insurmountable.  What you'd expect, I would guess.

> I don't honestly think there is any point in trying to parallel maintain
> and/or generate both shell and C versions at all.

In part, that depends on how long the various feature freezes have to go on.
Let me know if you all go forward with it.

Cheers - Bruce