On 07.12.15 13:34, Paolo Bolzoni wrote: > On Fri, Dec 4, 2015 at 7:05 PM, Erik Christiansen > <dva...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.