avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc
Date: Thu, 17 Sep 2009 21:35:00 +0200
User-agent: Mutt/1.5.11

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/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]