Re: [Avr-libc-corelib] proposed corelib style guide

[Ruddick Lawrence]

I agree that we should not officially "support" a source version, but I do not think we should explicitly discourage or make it overly hard for people to get the source code (I'm pretty sure you can allow anonymous check outs with CVS, and Doxygen can generate pretty code webpages for each file). I bet most of us started out as hackers, and it really helps to find source code that does ALMOST what you want, and be able to figure out where you can modify it for your specific purposes.

I see our responsibility as commenting the code (even private) well, and making sure people can find the source. Beyond that it's definitely "at your own risk."

On Wed, Sep 23, 2009 at 1:09 AM, Ron Kreymborg <address@hidden> wrote:

> I would add (from the user's viewpoint):
>
> MODULES
> - Each module will have a usage guideline and a comprehensible example
> of use
>
> I would anticipate that users will copy the library files to their
> projects, potentially modifying them, rather than use a pre-built
> library or such.
> So the usage guideline should include a method how to add all that's
> necessary into a makefile, preferrably "compatible" with mfile's
> "standard" output (or shall we attempt to expand mfile's capabilities
> accordingly?)
>
> JW

As I understand it, the library will be a pre-compiled lib file, with the
MCU name in the makefile linking to the matching version for that processor.
Maintaining a source version would be nigh on impossible. Imagine: "I
increased the buffer limit and changed the speed setting and now my app
resets about every 5 minutes. Help!".

I suggested earlier that the current source be available (not necessarily
with an avr-avr release but perhaps on a web site somewhere) after the
library is also released in its current final version. This would be "modify
at your own risk". Any other suggestions?

Certainly there will be at least one example for each module.

Ron