Joerg Wunsch wrote:
Good morning, Eric ;-)
Good morning!
After this, I'll be starting my daily 2-hour drive ;-)
fine by me. How to call the version string (like "1.4.0") then?
__AVR_LIBC_VERSION_STRING__? Accompanied by
__AVR_LIBC_VERSION_DATE__, which is also a string (like "200508
Good morning, Eric ;-)
> >fine by me. How to call the version string (like "1.4.0") then?
> >__AVR_LIBC_VERSION_STRING__? Accompanied by
> >__AVR_LIBC_VERSION_DATE__, which is also a string (like "20050829")?
> I like *_STRING__, IMO.
I.e., __AVR_LIBC_VERSION_STRING__ and __AVR_LIBC_VERSION_DA
Joerg Wunsch wrote:
As Bob Paddock wrote:
'releaselevel' sounds better than _PATCHLEVEL_ which implies bugs,
and _TINY_ is a bit to vague, since there are TINY AVR parts.
Well, yes.
I feel the standardized macro to have a single test for a
particular release to be a big win.
As Bob Paddock wrote:
> 'releaselevel' sounds better than _PATCHLEVEL_ which implies bugs,
> and _TINY_ is a bit to vague, since there are TINY AVR parts.
Well, yes.
> > I feel the standardized macro to have a single test for a
> > particular release to be a big win.
> Yes to both items, single
Joerg Wunsch wrote:
I'm not that happy about `patchlevel' (actually, it's probably rather
`releaselevel' for us, but as the release number consist of all three
elements, that would be confusing), that's why I've been searching for
a different name. I'm open for better suggestions though.
I c
On Sunday 28 August 2005 02:58 pm, Joerg Wunsch wrote:
> As Bob Paddock wrote:
> > > >. __AVR_LIBC_VERSION__ "1.4.0" /* a string */
> > > >. __AVR_LIBC_MAJOR__ 1/* three integers */
> > > >. __AVR_LIBC_MINOR__ 4
> > > >. __AVR_LIBC_TINY__0
> >
> > As do I. GCC refers to _TINY_ as
As Bob Paddock wrote:
> > >. __AVR_LIBC_VERSION__ "1.4.0" /* a string */
> > >. __AVR_LIBC_MAJOR__ 1/* three integers */
> > >. __AVR_LIBC_MINOR__ 4
> > >. __AVR_LIBC_TINY__0
> As do I. GCC refers to _TINY_ as _PATCHLEVEL, see below.
I'm not that happy about `patchlevel' (actua
On Friday 26 August 2005 12:54 pm, E. Weddington wrote:
> >What to put in there?
> >
> >. __AVR_LIBC_VERSION__ "1.4.0" /* a string */
> >. __AVR_LIBC_MAJOR__ 1/* three integers */
> >. __AVR_LIBC_MINOR__ 4
> >. __AVR_LIBC_TINY__0
>
> I actually prefer this method,
As do I. GCC
Joerg Wunsch wrote:
It has been requested every now and then that there be a user-visible
library version number. I'm about to start this with the impending
release of the 1.4 branch, so here are a few questions.
What to put in there?
. __AVR_LIBC_VERSION__ "1.4.0" /* a string */
. __AVR_LIB
On Wed, Aug 24, 2005 at 09:55:24PM +0200, Joerg Wunsch wrote:
> . __AVR_LIBC_RELEASE__ 0x010400 /* a single integer */
> Of course, we could provide , and then include it
> from (and document it that way).
These are the options that I think would work well for me. I like
the idea of adding t
As Russell Shaw wrote:
> Maybe the release date could be added as an extra macro: 050825 for
> Aug. 5th, 2005.
OK, except I'd use MMDD.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operatin
Joerg Wunsch wrote:
It has been requested every now and then that there be a user-visible
library version number. I'm about to start this with the impending
release of the 1.4 branch, so here are a few questions.
What to put in there?
. __AVR_LIBC_VERSION__ "1.4.0" /* a string */
. __AVR_LIBC
It has been requested every now and then that there be a user-visible
library version number. I'm about to start this with the impending
release of the 1.4 branch, so here are a few questions.
What to put in there?
. __AVR_LIBC_VERSION__ "1.4.0" /* a string */
. __AVR_LIBC_MAJOR__ 1/*
13 matches
Mail list logo
