Hello all,

I rarely see dialogue exchanged on this PICLIST with regard to creating
libraries with MPLIB and I was hoping that someone would be able to offer me
some guidance and/or advice if you have the time. I'm hoping this could
generate some discussion since the benefits of libraries are enormous (even
for individual developers). I have been re-using code the 'copy and paste'
method for too long and it's time I start using MPLIB for organizing code
and real re-usability.

To keep things simple for starters, I've decided that I want to create an
ASM library specifically targeted for the PIC18F452 right now. I've been
using MPLINK, but I've never used MPLIB and created libraries before and
there's some questions that I have that I have not seen covered in the
'bible': MPASM USER'S GUIDE with MPLINK and MPLIB (DS33014G).

First off, at a higher level, I'm wondering what are some good techniques
for eliminating the situation in which future modifications of library
member functions can 'break' the original interface (similar to avoiding DLL
hell of the Microsoft world).

For example if I have already released a library and have client code
already using it, I do not want to break the client code when I change the
interface or implementation of any library member functions in the original
library.


My plan to avoid this nasty situation is to do the following (I'll use a few
I2C routines as an example):

A) Always append a version suffix to the ASM name of all code that will be
converted to object file library member functions:

   i.e.  I2C_StartCondition_v10.asm
         I2C_RepeatedStartCondition_v10.asm
           etc

   (the 'v10' suffix in the name would be interpreted as version 1.0)


   The assembler will create the object files since I will be using the
linker:
         I2C_StartCondition_v10.o
         I2C_RepeatedStartCondition_v10.o
           etc


   Then I would build a library (I2C.lib) using MPLIB by adding the I2C
member function object files.



B) Then in the future, if I even needed to change the interface or the
implementation of the library member function (for whatever reason) I would
have a rule that you would NEVER modify any existing member functions in the
library -- you must create a new one and increment the member function name
suffix (version):

   i.e.  I2C_StartCondition_v11.asm
         I2C_RepeatedStartCondition_v11.asm
           etc

  (the 'v11' suffix in the name would be interpreted as version 1.1)


        Re-assemble, re-link, add new member functions to I2C.lib.


If these rules are followed, existing client code that uses the library
would not be broken. And, when using the library it would be very easy to
see which member functions are the newest due to the versioning method
employed in the member function name itself. Any new code written using the
library would most likely use the latest version of a particular member
function.


I would greatly appreciate it if anyone could take a stab at the following
questions I have:

1) Does this sound like a reasonable approach?

2) If not, does anyone use a different method to avoid breaking client code
when modifying a library member function (interface or implementation) is
necessary in the future?

3) What should be the maximum length of my library member function names?

   I can't seem to find out from reading MPASM USER'S GUIDE with MPLINK and
MPLIB (DS33014G) what this should be.
   It mentions that labels should be 32 characters or less -- maybe this is
the answer. I guess I'll go and experiment...


Thanks for everyone's time, help/advice, and consideration -- I appreciate
it!


Best regards,

Ken Pergola
























32 size?

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu