Well, I still have a couple of nags with my makefile. No biggies. It's working ok. But...
Code:
CPP = mingw32-g++
BIN = mediaeval.exe
SRCS = admin.cpp checksum.cpp # etc...
HDRS = admin.hpp checksum.hpp # etc...
ifeq ($(cfg), release)
OBJDIR = release/
CXXFLAGS = -Wall -Wextra -ansi -O2 -DNDEBUG
else
OBJDIR = debug/
CXXFLAGS = -Wall -Wextra -ansi -g3
ifeq ($(cfg), profile)
CXXFLAGS += -pg
endif
endif
OBJ = $(OBJDIR)admin.o $(OBJDIR)checksum.o # etc...
LIBS = \
-lsqlite \
-lpdcurses \ #etc...
#-------------------------------------------------#
.PHONY: clean
$(BIN): $(OBJ)
$(CPP) $(OBJ) -o $(BIN) $(LIBS)
ifeq ($(cfg), release)
strip $(BIN)
endif
-include .depend
%.o:
$(CPP) -c $< -o $@ $(CXXFLAGS)
#-------------------------------------------------#
clean:
rm -f $(OBJ) $(BIN) .depend
.depend: $(SRCS) $(HDRS)
$(CPP) -MM $(SRCS) > .depend
sed -r -i "s,^([a-z]+.o: ),$(OBJDIR)\1,g" .depend
Nag 1: Instead of issuing 'make cfg=release', for instance, as the above describes, I would rather much prefer 'make release'. Can I do this without having to turn release into a target? In other words, can I test for the existence of 'release' and 'profile' as if they were variables? <i>ifdef</i> seems to not be able to do it.
Nag 2: 'make clean' has the interesting side effect of calling .depend before calling clean if I do it repeatedly. I understand why it does it and it's not a big deal for the obvious reason. But i'm curious; can I control that -include so that it is not parsed when the target is 'clean'?
Also 1: Strip confuses me to no end. My executable compiled with -02 and no debugging symbols is around 2Mb (MinGW loves fat executables, bleh). However it can still be stripped of symbols down to 700k. Why? What symbols were these? What am I missing if I strip an executable compiled withough debugging symbols?
Also 2: I was surprised at the -M/-MM switches slowness. Look at the following small example I tested with only a subset of my source files:
Code:
admin.o: admin.cpp panelbuffer.hpp pdcstr.hpp admin.hpp mediaeval.hpp
crand.o: crand.cpp crand.hpp
crc.o: crc.cpp crc.hpp
mediaeval.o: mediaeval.cpp errmediaeval.hpp unit.hpp
menu.o: menu.cpp pdcstr.hpp admin.hpp mediaeval.hpp
panelbuffer.o: panelbuffer.cpp panelbuffer.hpp pdcstr.hpp
pdcstr.o: pdcstr.cpp pdcstr.hpp
unit.o: unit.cpp errmediaeval.hpp unit.hpp
The most you have there is a 2nd level dependency (should I say it this way?), in which admin.o dependency on mediaeval.hpp comes from admin.hpp, for instance. That output takes 5 seconds on my computer to be generated (PIII 1000, 512 RAM). Is this expected? Can it be improved somehow?