Open adicarlo opened 6 years ago
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!
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?
Pull request is in!
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:
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.