Follow-up Comment #4, bug #30363 (project avr-libc):
> But should <util/delah.h> be using autonconfig information directly
> to determine if __built_avr_delay_cycles() is available?
That's the way it is designed right now.
> Why not require it to be told this information at compile time (by
> <avr/builtins.h> ) and in the absence of being told whether these
> functions are built in, assume that they are not?
User won't use it then, ever. Who do you think would ever define that
macro then? The user in his Makefile? Nope, users assume things are
working out of the box. It's already hard enough to teach them they
have to configure -mmcu=XXX and -DF_CPU=XXX in their Makefiles
(because this information can _only_ be supplied by the user), I don't
trust them they would start investigate whether their compiler
implements a certain feature, and then set a macro based on that.
> Why can't <util/delay.h> include <avr/builtins.h> directly?
What would be gained by this, except of adding the overhead for
opening one more file? Both simply use the same auto-configured
macro.
> The ideal fix for something like this is to fix GCC itself to create
> defines for all built in functions.
I whished that, too, although I also think it's going to be a
pollution of the macro name space. Anyway, moot point, these macros
aren't there, and we've already got a hard time convincing the AVR-GCC
maintainers that we really want __builtin_avr_delay_cycles(). If we
extend that to first discussing that each builtin also ships with an
accompanying macro (which would then extend beyond the AVR-specific
feature set, thus require a generic GCC policy decision), we meet
again here in 3...5 years. I didn't want to wait that long, sorry.
Anyway, if you've got the energy to push such a policy change through
the GCC folks, I'll promise you avr-libc will be the first to use it
then.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?30363>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
