David Megginson writes: > Erik Hofman writes: > > > -rw-r--r-- 1 erik user 648823 May 12 2001 js-1.4-2.tar.gz > > -rw-r--r-- 1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz > > What does everyone else think? Should this be bundled unpacked in the > SimGear source tree and built automatically (as with expat, our XML > parser), bundled as an archive so that users can build it if they > don't already have it installed (as with metakit and zlib), or left as > an external, optional extra? I'd like to embed an interpreter in > FlightGear, and ECMAScript is an excellent candidate language, but it > would be nice if the interpreter were a lot smaller. > > Erik -- what do your bindings look like? > > Is anyone going to argue for embedding a small Scheme interpreter > instead? > > Does anyone know of a smaller ECMAScript implementation?
I would argue that if we do embed a script interpreter it should be really small, tight, and light weight. 1Mb of compressed source seems excessive ... this is almost exactly the same size as the entire flightgear source, so we'd be roughly doubling the size of our source and the time to compile ... If we include something that we want to maintain ourselves and not closely track some up stream 3rd party source, then it might make sense to unroll it in the source tree, integrate it with our build/install system, and distribute it that way. If it's something that comes standard or optionally with most distributions, then unrolling it and integrating with our own build system is probably going to be more trouble than it's worth, especially if we want to track upstream changes. We end up having to support platform and build issues which is a major PITA. In that case we could include a .tar.gz for the convenience of those that don't already have it installed ... like metakit and zlib. Also we need to consider that each new dependency we add significantly increases the barrier for new developers to get all the pieces in place to build their own executable. In light of this, having an external scripting system that uses a network interface becomes attractive. However, there can be performance issues with that which might be addressed by a built in script engine. I don't necessarily know enough about script interpreters to have a strong opinion as to how we should proceed, but I think these are the items we need to consider. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
