Running make should only rebuild the parts of the source that have changed, and any parts of the source that are dependent on parts that have changed. You will always have to do the final link (20-30 seconds), but it shouldn't hit too much else.
Ya, thanks for that - I know, but it's still 350 megs stuff that I need to keep on the drive, just for some minor changes ;-)
Sorry, if I wasn't clear about that.
Erik Hofman wrote:
Boris Koenig wrote:How about adding a sub-directory "lib" to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ?
What do you think ?
I don't particulalry like the idea. I'de much rather concentrate on imporving a FlightSimulator than on extening a scripting language.
I agree -that was actually the very reason why I suggested something
like that: *I* would take care of the plugin thing, so that *I* could easily add new Nasal stuff - and so I wouldn't have to bother you guys
too much with my requirements anymore ;-)
That way the number of bindings to Nasal are as low as possible whichnakes
it easier to use.
I agree again, but there are some things that I would need to be added to Nasal in order to really be able to use Nasal INSTEAD of doing things _primarily_ in C++.
And meanwhile, I've really come to the conclusion that I like the scripting approach - IF it allows for some more flexibility (see my previous postings)
I realize there might be a difference between people who want a scripting language to do everything they need and people who don't want a scripting language except for some very specific tasks.
Well, don't get me wrong - _I_ don't want Nasal to do everything, it's just that YOU suggested using Nasal instead of C++.
I don't want to make Nasal a fully bloated programming language,
but from what I can tell so far, there are about 6-10 additional commands that I might need in order to really be able to absolutely
drop the C++ approach and concentrate on Nasal.
So, my motivation is NOT to make Nasal bloatware, just to add things like support for :
- dynamic population of statically defined panels/dialogs
- simple file I/O (could be easily handleld by FlightGear
itself
- More advanced hooking techniques in order to allow for
some simple dragging and dropping of instruments/dialogs
within the authoring component of my FliteTutor concept.Regarding the latter, imagine a simple dynamic panel & dialog editor that would be written using Nasal - this could even be integrated into FlightGear itself, users would be able to create panels & dialogs by doing some dragging and droppinig of pre-defined FlightGear objects and this stuff would then be saved in a standard XML file using PropertyList syntax.
I am leaning towards the later (for FligthGear at least).
Yes, I can see - and this really wasn't meant to suggest Nasal should become a Visual Basic pendant within FlightGear - rather just for simpler adding of new functions/fgcommands.
---------- Boris
P.S.: I've added a screenshot section to the webpage (http://flitetutor.sourceforge.net) to show what I've done so far (STATICALLY, using XML files) and what I'd like to be able to do "on the fly" with Nasal.
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
