zach> [previous things] david>
Well, yes ... what eventually goes into /usr/include should be strongly limited to the interfaces. How anything gets implemented inside the library is nobody's busienss except for the library maintainers'. They should be able change how they do things easily. But that won't happen if all kinds of random implementation detail are cast in concrete as part of the public /usr/include interface to the library.
Really, we need to think *STRONGLY* about *NOT* creating "libopenocd" - I believe creating "libopenocd" will be a nightmare (ie: the implementation details in concrete)
I believe that a public *SOCKET* interface with a *TEXT* based protocol to OpenOCD is a *FAR*BETTER* choice.
Things are already in place for exactly this. http://svn.berlios.de/wsvn/openocd/trunk/doc/manual/server.txt?rev=1910&sc=1 <http://svn.berlios.de/wsvn/openocd/trunk/doc/manual/server.txt?rev=1910&sc=1> -Duane.
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
