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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
