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

Reply via email to