massively redundant makefiles

[adicarlo]

Rather than forcing the user to configure each and every makefile in each and every project directory, would you consider a refactor which made use of the GNU Make include ?

Ideally, I would think, we could provide one make snippet, in a common directory, for the user to configure, and another with the rules and targets and supporting stuff.

I work this way internally, and my per-project makefiles look like this:

# disable optimization when debugging!
COPTIMIZ	:= 

include ../../make-include/avr8.mak
include ../../make-include/basic.mak

all:	avr-training.html avr-training.pdf

If so, you can assign this issue to me and I can give you a pullable fork you can review. I wouldn't take literally the approach above, I would try to keep the the style of your stuff.

The only gotcha here is that this is a GNU make specific syntax if I am not mistaken. That compatibility issue might be a killer, in which case, just close the ticket.

[hexagon5un]

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!

[adicarlo]

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?

[adicarlo]

Pull request is in!