On Thursday 04 February 2010 14:46:59 CeDeROM wrote: > Maybe this is a good moment to set up the final API and the function > names+arguments to prepare UrJTAG to become a dynamic library? > > If UrJTAG becomes a library it should never rename function names and > its arguments count/order/meaning, only some new functinos can added > to extend functionality. This is very important issue to maintain > backward compatibility of such a library. I am considering to code > SWD/SWJ support to program my STM32 based device soon - I can choose > UrJTAG and OpenOCD, but it would be nice to see these two applications > cooperate each other to access low level stuff using a urjtag > library... and probably any new future application using UrJTAG.so > library...
i'm more than familiar with shared library policies, but for something that has grown organically like urjtag, i dont think it's reasonable to try and get it "perfect" the first time. if we screw up, we bump the SONAME and then we dont have to keep baggage around. i honestly dont think urjtag is an important enough piece of software atm that bumping the SONAME is going to cause enormous grief. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com
_______________________________________________ UrJTAG-development mailing list UrJTAG-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/urjtag-development
