[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 10:25:47 +0200 |
User-agent: |
Mutt/1.5.11 |
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/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, Ruddick Lawrence, 2009/09/17
Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc, David Brown, 2009/09/18