Hi all, Assuming a split between policy and mechanism can be addressed, OpenOCD will become much more usable as a proper library. One of the questions that needs resolution is "how to install our header files". The answer that we chose for this will determine how much restructuring will be required to make it happen.
The easiest option to simply mirror the public headers in our existing src/ hierarchy into /usr/include/openocd[-<version>]/, such that applications can use -I<that_path> and #include <<module>/<header>.h>. Indeed, I have a series of patches that accomplishes these changes for all <module>s and <header>s in the tree. (Via a script, so it's easy to recreate its patches when I get merge conflicts.) Of the options that I consider as viable, this is the least invasive and most flexible. Each source module gains its own namespace for header files, allowing us to adopt some common idioms across modules. An alternative would be to install all headers in the above location, but that flattens our namespace and prevents some useful possibilities. For example, it would be nice to be able to #include <<module>/core.h> and <<module>/tcl.h> for each of our modules. These should permit writing very low-level or a script-based applications with built-in commands that use our modules' helper functions, respectively. We should approach this problem as though we intend to eventually decouple Jim from the core functionality and switch to a different front-end language. That would take a lot of extra work, but the preparation would yield solid architectural improvements to the system. Even if we never do that (and there's no reason to), the system will be cleaner for our efforts; it's classic model-view-controller separation. It would be the best way to make Jim 2.0 feasible, wherein its APIs can change wholesale while remaining backward-compatible with 1.0 scripts. Getting from here to there will require a number of large patch series, but I see this specific conversion as being required for writing a proper test suite. Tests should be written for our APIs in the same way as real applications, and the helper API is reaching a state where I want to start a test suite for it. Yes, I have patches started for that in my tree as well, built on the above series. If libocdhelper can become usable independently of OpenOCD, that will be a huge a step in the right direction. I think it's possible very soon. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development