Re: [avr-libc-dev] [bugs #12033] macros.inc need to be protected from multiple inclusion.

[E. Weddington]

Joerg Wunsch wrote:

> As E. Weddington wrote:
>
>  
>
> > But surely making macros.inc idempotent is useful too?
> >    
>
> I'd even do the opposite: fplib.inc used to have the #ifdef magic on
> top, I'm inclined to remove it.
>
> As these files are deemed to be internal to the library (and not
> intented for use by end-users), I'd consider it a bug if someone wants
> to include one of them more than once.
>
> I'd rather like to untangle all that macro spaghetti some day.
> Ideally, there would be no more than a single central header file
> needed for the entire library (plus perhaps local files, as we have in
> stdlib_private.h etc.).  It always annoyed me how complicated it's
> right now to see which register actually belongs to fplib's rA2, or
> rAE etc.
>
> If we think some of the macros there are good for users, too, we could
> always put them into an exported header file.
>
>  
Oh, ok, now I get it.

I definitely agree about removing the macro spaghetti. I always found it 
frustrating to have to write modules for avr-libc with macros such as:
------------------------------------------
   .global    _U(memcpy)
   .type    _U(memcpy), @function
_U(memcpy):
   LOAD_Z(src_lo, src_hi)
   LOAD_X(dest_lo, dest_hi)
------------------------------------------

What with _U(), LOAD_Z(), LOAD_X(), etc.

Agreed, that if some are useful (arguably the LOAD_Z(), LOAD_X()) then 
keep them but expose the API.

Whew! We're getting bigger projects by the minute. :-)

Eric