massively redundant makefiles about avr-programming HOT 3 OPEN

I won't lie -- I'm not happy with the make/build system for the code in the book. There are two competing tensions: a) it's nice to have each chapter's code self-contained and b) it creates a lot of redundancy to have each chapter self-contained.

There's also an existing gotcha -- because of the way the CPU speed is incorporated in the Makefiles, it needs a "make distclean" when it's changed or else the already-compiled USART.o will come in with the wrong speed. But because you can always pass F_CPU as a command-line option, I don't know an ironclad way around this except to recompile everything all of the time, which is probably the right thing to do.

F_CPU aside, I think the Makefile is the same (or varies in the .c filename, which is autodetected from the directory name) anyway. This probably makes the Makefile.inc idea even more reasonable -- toss that in the library folder and be done with it.

And because of that fact, I think it'd be very easy to restructure the way you're thinking. Or maybe split the makefile up into a programming-logic section and a flash-programming section, leaving the main defines (chip, CPU, baud) in each directory?

Have at it and submit a pull request! I'll open up a development branch and hack away as well. I'm going on vacation for a couple weeks, but will have time to review stuff afterwards.

Thanks!

from avr-programming.

hexagon5un writes:

I won't lie -- I'm not happy with the make/build system for the code
in the book. There are two competing tensions: a) it's nice to have
each chapter's code self-contained and b) it creates a lot of
redundancy to have each chapter self-contained.

Totally understand, and that's why I wanted to know if the work was
welcome before embarking on it.

There's also an existing gotcha -- because of the way the CPU speed is
incorporated in the Makefiles, it needs a "make distclean" when it's
changed or else the already-compiled USART.o will come in with the
wrong speed. But because you can always pass F_CPU as a command-line
option, I don't know an ironclad way around this except to recompile
everything all of the time, which is probably the right thing to do.

Well, its pretty conventional with C makefiles that if you change
CFLAGS, you're going to have to 'make clean' to get good results.
So I wouldn't stress too much over this one.

F_CPU aside, I think the Makefile is the same (or varies in the .c
filename, which is autodetected from the directory name) anyway. This
probably makes the Makefile.inc idea even more reasonable -- toss that
in the library folder and be done with it.

And because of that fact, I think it'd be very easy to restructure the
way you're thinking. Or maybe split the makefile up into a
programming-logic section and a flash-programming section, leaving the
main defines (chip, CPU, baud) in each directory?

Have at it and submit a pull request! I'll open up a development
branch and hack away as well. I'm going on vacation for a couple
weeks, but will have time to review stuff afterwards.

Ok, great. I'll try to work out something that seems natural. I'm hearing
that you'd prefer per-directory configuration of basics (baud and CPU etc),
no objections there.

Does it make sense to assign this ticket to me?

from avr-programming.

Pull request is in!

from avr-programming.