Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc

[Ruddick Lawrence]

I'm game if Ron and Frédéric are willing. I have extensively used the
simpler aspects of SVN (ie, no branching or merging), and I hear CVS is
similar enough.

I agree we should move further discussion to a dedicated list in order to
stop bugging people here who are uninterested. As for the name, do we want
to tie it to avr-libc in any way (but not as confusingly as Procyon AVRlib
did...)? Something along the lines of avr-libc-extension. Or it can be
completely whimsical, such as avr-packmule (it does the heavy lifting).

Ruddick

On Thu, Sep 17, 2009 at 12:35 PM, Joerg Wunsch <address@hidden> wrote:

> As Ron Kreymborg wrote:
>
> > I now have a little more spare time, so would be willing to join as
> > a volunteer for this library.
>
>
> As Frédéric Nadeau wrote:
>
> > I started such a project at the beginning of the year. Please check
> > at: http://code.google.com/p/avr-drv/
>
> > [...] I'm
> > willing to work on that and would see no objection to actully give
> > that code to the AVR-LIBC project.
>
>
> As Ruddick Lawrence wrote:
>
> > I am willing to help develop and maintain such a library [...]
>
>
> Cool!  That makes three of you, I think that's enough for a start.
>
>
> How to proceed from here?  Do you all have CVS experience?  I think
> the next step would be to discuss an API.  I think it might make sense
> to setup a different developers list so things like that API
> discussion could be done there.  Oh, that also asks for a name for the
> new library then ;-), as that name should probably be reflected in the
> name of the mailing list.
>
> What do you thkin about it?
>
>
> As Ruddick Lawrence wrote:
>
> > ..., but I am more enthusiasm than experience, and
> > obviously it would need more developers.
>
> I'm willing to act as a consultant for technical details, like
> organization of the CVS tree, and I could get you going on how to roll
> a release.  If you are willing to establish an autoconf/automake
> infrastructure, you could basically re-use the release preparation
> instructions from avr-libc (which are described in detail in the
> documentation).
>
>
> As Ron Kreymborg wrote:
>
> > I guess it would be a library of modules with a documented API for
> > each. The trick would be to ensure any common code in modules from
> > various contributors is extracted out into the one place. Otherwise
> > including more than one module could mean possible code duplication.
>
> Well, that certainly needs to be discussed.  But don't worry too much,
> a consistent and relatively stable API is more important than details
> like how to avoid code duplication.  Then, as long as you stay with
> the API once agreed to, anything else will be details internal to the
> library, which could be easily changed between releases.
>
> --
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
>
> http://www.sax.de/~joerg/ <http://www.sax.de/%7Ejoerg/>
>      NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>