Joerg Wunsch 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.
Can I add a few comments here? First I'd like to applaud the volunteers
here - enthusiasm is more important than experience for a project like
this, and I think it is great that you are able and willing to spend
time on this library project. The world of embedded development has too
many people like me - lots of experience, but little time to spread it
around since we work too much!
One thing I'd like to suggest is that the "library" be divided into
separate areas. In particular, I'd like to see a "stable" area and a
"staging" or "experimental" area. A module will only be moved into the
stable area after it has been well tested on a variety of devices,
documented, and after the maintainers and the mailing list have
generally agreed that it is ready. These will be modules that users can
rely on, and which the library maintainers are committed to maintaining
over time.
The "staging" area would be for modules that are proposals. They should
be good enough for people to make use of if they want, but there are no
guarantees about stability of the code or the APIs. This gives you an
area for code that you'd like to see tested by others, without the risk
of being stuck with a sub-optimal API or implementation.
There may also be a "what you see is all you get" area, where you can
keep code that is donated but not documented, maintained, tested, or
otherwise ready for the main library. This would provide a cheap entry
point for people who could provide code, and users can take it or leave
it. If the code looks generally useful, it could then provide a
starting point for a full library module. This should of course not
just be a dumping ground for any old code.
What I'm aiming at here is a way to get more code into the project, and
to allow different levels of completion (including documentation,
generalisation, testing, ABI stability, code style, and commitment to
maintenance) for different modules. Modules of common use to beginners
must have a higher standard and ease of use than unusual modules useful
only to a few. And it is very important that these distinctions are
made clearly, so that users know what they are getting.
Joerg has suggested using avr-libc's system for building and
infrastructure, which would be a good starting point. However, I think
you should be open to other ways to use the code than as a traditional
static library build combined with header files.
For some modules and uses, it could be more practical for users to
simply add the module's C and header files to their project. There are
several advantages to this - debugging is easier, code optimisation is
better (it will compiled with the same flags as the rest of the project,
possibly including --combine and -fwhole-program), it is easier to keep
the code stable (especially if the module is not from the "stable"
area), and it is easier to modify the code.
Making the modules re-usable in this way might mean more effort is
needed in making the modules stand-alone, or at least with clearly
specified interdependencies. This is perhaps a good thing in general,
as modules will typically be written by different people. Another issue
is licensing, although I think the avr-libc license allows such use even
with modifications to the library modules.
You might also want to have areas set up as a wiki for information, and
perhaps areas for sample code (either full demo programs or code
snippets). But that would perhaps be stretching the scope of the
project too far.
On a practical point, having a separate mailing list is a good idea, but
with announcements copied to the related lists (like this one). It
would also be nice to have the list registered at gmane.org - I find
gmane.org very convenient for many of the lists I follow.
mvh.,
David
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
