Re: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible withiom168.h

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Joerg Wunsch
> Sent: Tuesday, May 24, 2011 3:17 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible
> withiom168.h


<snip> 
> I took that idea to generate the avr-libc XML format (but never
> committed those files itself to the tree), and used that as a base for
> the interrupt documentation.  This also included a kind of
> backannotation of the SIG_* vector names (which cannot be safely
> deduced from the Atmel XML files).
> 
> But that's now all obsolete, as I never maintained that flow, and
> we've now got yet another converter, basically required for the Xmega
> stuff (which was not covered by Ted's design).

Ah, I see.

> > There is also the issue of deprecations. Deprecations in the IO
> > header files can't easily be automated. You end up with exceptions
> > to a build script for almost every single header file. This
> > necessitates maintaining the header files by hand after the
> > *initial* header file generation.
> 
> No, it could have been handled by adding an attribute in the avr-libc
> XML.

The only downside I see with that, is that the XML files then have to be 
maintained by hand. Something has to be maintained by hand, whether source XML 
file, or header file. At least with the current system, we only have one set of 
files (headers) to maintain.


> > Speaking of which, you closed a bug or two recently with some
> > renamed values. You haven't answered yet my email about if you want
> > to deprecate the old names using our new deprecation system...
> 
> Sorry, I forgot.  No, I wouldn't deprecate them.  After all, users
> might have written code based on a (once) legitimate copy of that
> AVR's datasheet, using a name described there.  Even though the
> current datasheet doesn't mention that name anymore (and in many
> cases, it doesn't even mention that renaming in the datasheet
> history), it has once been valid, and it's not the user's fault.
> 
> After all, renaming actions like this one have been very rare.

Except that the older names were always commented as deprecated. We need to 
decide on a policy and stick with it. I would think that if an identifier in 
the XML file was renamed, that we deprecate the old one, and add the new one.
 
> Btw., with all the poisoning of the SIG_* vector names, some existing
> code out in the field won't compile out of the box anymore, 

Well, that's kind of the point. It can be recompiled successfully with a 
conditional definition before the headers are included.

> so I think
> the next avr-libc version will be named 1.8.0 (rather than 1.7.2) to
> make the users aware of the larger change.

Ok, I support that.

Eric