Bob Friesenhahn wrote: > > When evaluating the direction to take for a C-based libtool, I tend to > think of libtool being similar to `make' in that it is a rules > processor. The process of "configuring" libtool would be a matter of > selecting which collection of rules applies to the current system. I > see that the "rules" are scripted somehow (could use /bin/sh as `make' > does) and are easily changed, but the core libtool engine works > identically on all platforms, and does not need to be based on > scripting.
What an excellent idea! Care to throw together a straw-man design?
> The main argument to use a VM for internal libtool logic
> would be to reduce code size so the libtool footprint is smaller.
Depending on the language chosen as input to the byte-code compiler, we
might also be able to come up with something that is a better fit for the
problem space.
Writing rules-based ltmain in C might take a lot longer than writing
it in a higher level language, and will probably take longer to work
the bugs out of.
I am not (yet) especially in favour of either C or an as yet undetermined
byte-compilable language, but I would definitely like to explore the
idea of replacing the creaky old ltmain.sh code :-)
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
