On Fri, 2009-12-04 at 11:38 +0100, Øyvind Harboe wrote: > >> There would have to be some huge advantage or some > >> robust way of getting retesting done. > > > > Actually... there's a very simple idea: heterogeneous language support. > > To me that sounds like a disadvantage. I like the simplicity and confines > of jim tcl.
That is your choice. Would you deprive me of mine, given that it can be done out-of-tree? However, be careful. If you would push my out of the tree, what would prevent me to push for Jim to be moved out of it too, putting all front-ends on equal footings? Better be prepared to get used to installing both libopenocd and openocd-jim.... Unity is better. It can be done cleanly, so there is no technical reason to force forks to add major features like this. > >> Your improved design can facilitate such a disaster so we should > >> handle this carefully. > > > > Yeah, having lots of front-ends like GCC would be a total disaster. > > Apache, LLVM, Eclipse: they'd be much better of without so much choice. > > > > No, wait... the other thing... yeah: the exact opposite of that. ;) > > That was a thoroughly unconvincing analogy. > > Why don't we maintain OpenOCD in multiple languages? Why > should a user *have to* develop OpenOCD in C??? > Right... a single source code is an advantage! :-) Your analogy is equally flawed, in so far as we'll still have the C libraries... which will be stronger for having multiple front-ends. I think you are failing to see the benefits that re-use would bring to the core OpenOCD libraries. Multiple languages opens the door to support that we will not get today, because some users will not want to use TCL. With them, the libraries will get polished into shining beacons for all that want to write JTAG-related applications (betcha'). In any case, the best language upgrade would be Tcl -- either Jim 2.0, real Tcl/Tk support, or just to support a radically new command syntax. Any of which require the changes I suggest. Other languages is really rather far fetched given existing momentum, but that hardly diminishes the benefits that allowing them will bring to the existing code. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
