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

[Joerg Wunsch]

As Weddington, Eric wrote:

> Well I'd say that that is a theoretical difference. As we've seen,
> we can't rely on the fact that the XML device files are always
> up-to-date. We have plenty of situations where the datasheets are
> updated first and the XML files are afterward, even by some amount
> of time.

Ted's idea about the data flow has been different.  As we are not
allowed to store the original Atmel XML files in our repository
anyway, he would convert them into avr-libc specific XML files which
we are allowed to store, and which we could continually maintain.
Those files then serve as a master for all the ioXXX.h files, so you
could regenerate them as you need – if you need a new feature in the
header file, just change the converter, and regenerate all of them.

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).

> 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.

> 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.

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, 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.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)