Alan B. Pearce wrote:

> Have a look at Olin's development environment. As each file is
> assembled the .o file is added to a library for the linker to use. I
haven't checked the
> MPLINK documentation to see if this is necessary, I just use it :))
>
> Your scheme looks sensible to me, except you may also want to add a
> processor ident to the library name.


Hi Alan,

Thanks for your response Alan.

I guess the main reason I have not used and invested my time in Olin's
environment is because it is not in my total control. In other words, I'm a
little hesitant investing a lot of time and energy in it when I don't know
for certain if he will continue to offer and maintain it. Maybe that's a
lame excuse on my part or my ignorance of his environment. But sometimes the
only way for me to learn is to trip over your own feet and that's why I
wanted to invest some time in my own library. Creating a library is easy.
It's the library planning and foresight needed that comes with experience
that I don't have right now. That's what prompted my original question.

I'm only focusing on a library for the PIC18F452 right now and I realize
that not everything can be thrown in a library, but with careful thought, a
sensible library can be created in my opinion.

But my main post was more of a planning strategy in terms of configuration
management with regard to a library. Configuration management issues will
surface regardless of whether you are using a "source code library" or a
"binary library" (DLL analogy).

I'm most interested on hearing people's strategies on tacking these
configuration management issues I raised in my original post (having the
freedom to make future interface/implementation changes but at the same time
ensuring backward-compatibility with existing client code).

Thanks again Alan for your time.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads