On 07.12.15 13:34, Paolo Bolzoni wrote:
> On Fri, Dec 4, 2015 at 7:05 PM, Erik Christiansen
> <dvalin@internode.on.net> wrote:
> > The more structured approach also simplifies matters if it is decided to
> > place the source code under version control, but not anything generated.
> > (YMMV. And version the compiler in that case ;)
>
> This is a good point indeed, I guess it is time to learn cmake or
> something similar to make this step easy, as manually written Makefile
> s do not really make easy multidirectory projects. Do you know a good
> cmake tutorial for attention-span depriveded people? I read "Mastering
> Cmake" is quite good, but so expensive...
I've never heard of cmake (in 30 years in software development), and
have only used gnu make. (The only disadvantage with that is that it is
a superset of most "makes", and it can be annoying to have to downgrade
a makefile if ever forced to used a less capable "make". (I.e. never, in
my experience.) If automating, have you looked at "automake"?
OK, I did buy the O'Reilly "make" book a couple of decades back, and
thoroughly appreciated having it to hand. It covers some other "makes",
and gave good coverage of gmake. However, it is doubtful that any
expense is necessary:
https://www.gnu.org/software/make/manual/
HTML for having open in a browser window, and a plain text copy for
searching, perhaps?
I don't think I've ever found it necessary to write a makefile to
recurse through directories. (Because my code trees have not been
horribly deep.) It is not necessary to do so merely in order to separate
source and object files.
Note: The (essential) modeline in the following makefile snippet keeps
this on-topic, even for pedants.
------------------
# vim:noexpandtab
INC_DIR=include
OBJDIR=obj
CC = avr-gcc
CFLAGS = -g -x assembler-with-cpp -mmcu=atmega328 -DMCU=atmega328
AS = avr-as
ASFLAGS = -gstabs -mmcu=atmega328
LD = avr-ld
LDFLAGS = -M -T ../ld.lnk
.SUFFIXES :
.SUFFIXES : .c .h .o .s
%.o: %.s
$(AS) -I$(INC_DIR) $(ASFLAGS) -o $(OBJDIR)/$@ $<
%.o: %.c
$(CC) -I$(INC_DIR) $(CFLAGS) -c -o $(OBJDIR)/$@ $<
.PHONY: all app boot
all: app boot
( cd $(OBJDIR) ; $(LD) $(LDFLAGS) -o all.elf app.elf bootloader.elf > all.map)
avr-objcopy -O binary obj/$@.elf obj/$@.bin
...
------------------
That worked with the makefile, linker script, and the obj directory in
src/. If obj/ needed to be beside src/, then a OBJDIR=../obj goes a long
way to achieving that aesthetic. (OK, that example runs the assembler on
assembly language source files, the compiler on 'C' source files, and
finally the linker. (Boring intermediate targets omitted.)
I've never resorted to the mailing lists:
http://savannah.gnu.org/mail/?group=make
but have no doubt that there's very useful help to be had there.
A good bit of good manual reading, with caffeine drip (and donuts,
preferably), can save a lot of hair tearing when futzing with make.
(Don't ask me how I know that. :)
Erik
P.S. Apropos the advisability of recursive make, I have this note from
back in the days when I considered doing such things:
"Recursive Make Considered Harmful": http://aegis.sourceforge.net/auug97.pdf
An alternative, from info make:
-------------------------------
By declaring the subdirectories as phony targets (you must do this as
the subdirectory obviously always exists; otherwise it won't be built)
you can remove these problems:
SUBDIRS = foo bar baz
.PHONY: subdirs $(SUBDIRS)
subdirs: $(SUBDIRS)
$(SUBDIRS):
$(MAKE) -C $@
foo: baz
Here we've also declared that the `foo' subdirectory cannot be built
until after the `baz' subdirectory is complete; this kind of
relationship declaration is particularly important when attempting
parallel builds.
-------------------------------
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thursday, December 10, 2015
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment