I am willing to help develop and maintain such a library (I was the original poster, mrjogo, fyi), but I am more enthusiasm than experience, and obviously it would need more developers. Are other people on this list interested in helping with this (donating code, but more specifically the longer-term commitment to maintaining it)? I think it could be a valuable addition to avr-libc and the AVR community.
Ruddick On Thu, Sep 17, 2009 at 1:25 AM, Joerg Wunsch <j...@uriah.heep.sax.de> wrote: > As Ruddick Lawrence wrote: > > > I guess the first thing to figure out is > > how you (and the other developers/maintainers) define the scope of > avr-libc, > > and how best to design a complementary library (if at all) to house > useful > > code that is outside of that scope. > > Ideally, if there were enough volunteers to develop *and* maintain > such a library (this includes maintaining documentation, handling bug > and patch tracker submissions, rolling releases etc.), I could think > of the avr-libc project being able to house it as a relatively > standalone project. It could get a separate top-level directory in > the CVS tree, and roll separate releases from there. > > That way, users could decide whether they just need the low-level > stuff from avr-libc, or want a higher level of abstraction, and install > a second library on top of that. > > However, the biggest issue with that approach is finding enough people > who are willing to actively work on that. I don't see those who > currently maintain avr-libc having enough vacant resources to manage > such a project. (That doesn't mean we were completely "out" of such a > project, it's only we've got our hands full with maintaining the > current state of avr-libc.) > > So, volunteers welcome. ;-) > > Lacking that, I agree with Eric that some fairly low-level interface > abstractions might also go into the "classic" avr-libc, thereby > extending its scope a bit. However, if there were enough developers > for a separate library, its scope could be much beyond the current > avr-libc, so things like a generic HD44780 driver API could be there > as well. (Feel free to pick the current implementation from the > stdioexample as a starting point.) > > I agree to the person in that thread about the GPL issue; in order to > keep such a project under the roof of avr-libc, I'd say using the same > licensing conditions as avr-libc is pretty much mandatory, as this has > shown to cause the least trouble to every potential user so far. This > in turn would not allow re-using code of Pascal Stang's library, but > of course, re-using ideas or APIs does not constitute a licensing > issue. > > -- > 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 > AVR-libc-dev@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-libc-dev > _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
