Hot answers tagged

7

Making sources? The line all: $(SOURCES) $(EXECUTABLE) asks make to build $(SOURCES), in this case helloWorld.cpp. Is it possible to build it? Strictly speaking there are situations when you do want to build the source file (e.g. fetch it from git/cvs/sccs) but it is not applicable here: no rule is provided. Generally you don't want to build something ...


6

You should pick a single make variable usage style and use it consistently. Personally I use $(...) to avoid confusing it with shell variable ${...} (as I use that much more frequently than command substitution). You probably want to make all as phony also. Your run target will fail if run first thing. Using run: $(OUTDIR)/terminal will cause it to ...


6

Stem rules: Spelling out compilation rule for each object file is tedious and error prone. $(TEMPDIR)/%.o: $(SRC)/%.c $(CXX) $(CFLAGS) -c $< -o $@ takes care about all of them. Autodependencies: Spelling out dependencies for each object file is tedious and error prone. gcc can do it for you: $(TEMPDIR)/main.d: $(SRC)/main.c $(CXX) $(CFLAGS) -...


5

.PHONY: checkout all clobber clean $(checkout.all) There's no clobber target, so I think that will be ignored. The root variable is unnecessary (CURDIR should be well known by anyone using make), and is even defined twice. names=$(shell cat etc/projects.txt) In my experience it's more common to write out the list in the makefile. If this is so long as to ...


4

There is no need to pass linker flags to the compile stage. You only them when you link the final executable. Traditionally (aligned with make defaults) the flags variables are CFLAGS for C compiler, CXXFLAGS for C++ compiler, and LDFAGS for the link stage specifics. It is not recommended however to have -c as a part of CFLAGS: the CFLAGS can be reused for ...


4

I see some things that may help you improve your program. Don't use unneeded macros The AC_C_CONST is only used to compensate for either a C compiler that doesn't fully support the const keyword or when a C++ compiler is used to compile C code. Since CFLAGS has -std=gnu99, it's clear that this project is assuming either gcc or clang, both of which have ...


4

It looks pretty good to me, but I see a few minor things that might be improved. Specify which perl to run I'd recommend not leaving it to chance as to which instance of perl is run. Instead, for both safety and consistency, it might be better to do this: PERL=/usr/bin/perl ##... @$(PERL) -e '$(HELP_FUN)' $(MAKEFILE_LIST) Allow multiword category tags ...


4

Dependency Propagation One thing that's missing is dependency propagation. So each .o file will be recompiled only if its corresponding .cc file has changed. This is good, I don't want to have to recompile foo.o just because I changed bar.cc. However, what if both foo.cc and bar.cc include some other file quux.h, and you changed some of the function ...


4

A couple of things I dislike about your set up. Your low level make file in the top level directory. You only have one object directory (so you can only have one type of build) I have four types of build debug/release/coverage/size(built with size optimization) You use explicit commands where the makefile internal rules will work just as well. 1: At the ...


4

You should be able to simplify the definition of DEPS to DEPS := $(OBJS:.o=.d) For small projects that don't require complicated configuration schemes, it's often times easiest to get the list of source files by wildcard instead of manually maintaining an explicit list: SRCS := $(wildcard $(SRCDIR)/*.c) OBJS := $(patsubst $(SRCDIR)/%.c,$(OBJDIR)/%.o,$(...


4

It's reasonable to require GNU Make - it's available on all platforms that have their own Make (as far as I know), and trying to cope with the vagaries of all vendors' Make implementations is an exercise in futility. So I think you've taken the right approach here. You're working against Make by putting build products into subdirectories. It's easier to ...


3

I’m only going to comment on the argparse part. For starter, for function calls with long names and rather long value (esp. the help one), I mostly prefer the second indentation proposed by PEP8; but it's mostly a matter of taste. Speaking about PEP8, it also state that you should remove spaces around the = sign for named arguments. Second, I like to make ...


3

Instead of defining your own compiler variable, I would override the implicit CXX variable. This also goes for the implicit CXXFLAGS (instead of your ccflags). This allows other users to easily change the compiler used when using a different environment than you. You might also want to remove all the leading @ in favour of make -s


3

Generally good, clean and straightforward. Few notes however: Too many comments. Group CFLAGS assignments together. I am kind of surprised that -g is set regardless of DEBUG_BUILD. Speaking of debug, it usually helps to separate debug and release targets (different directories, different CFLAGS). I recommend to abstain from relying on environment variables (...


3

Disclaimer: I'm not experienced with this field, but this question definitely needs some activity, so this is my attempt at an answer. If there's anything that you want me to cover that I don't mention here, just tell me about it and I'll try my best to see what I can do. Style/nitpicks I find that some of your rule indentation is a bit excessive, and ...


2

What is the header file's name? The point being that the name of the header file, like xopen.h should have some connection to the items inside. Further, the objects declares and macros defines are all over the name space. Consider some convention. Put do_...() in do.h, CommandEntry in CommandEntry.h. Strange #define. Did you mean #define VERSION "v0.1a"...


2

CFLAGS The CFLAGS are C-specific and you always want to use CXXFLAGS for C++ code. You can expand the CXXFLAGS a bit so that you can write really compact code. I use this set of compiler options for both C and C++: -Wall -Wextra -Wfloat-equal -Wundef -Werror -fverbose-asm -Wshadow -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wstrict-overflow=5 -...


2

Use target- and pattern-specific variables: $(ldpi_dir)/btn_%.png : GEOMETRY := 24x $(mdpi_dir)/btn_%.png : GEOMETRY := 36x $(hdpi_dir)/btn_%.png : GEOMETRY := 72x and similar definitions for launcher_%.png Then you can combine all the individual recopies into a single one: $(ldpi_dir)/%.png $(mdpi_dir)/%.png $(hdpi_dir)/%.png) : convert -geometry $(...


2

You can do this in pure make if you'd like (that is, without requiring an external tool like Perl). John Graham-Cumming has a detailed explanation of it on his blog, but here's the short version. You can add documentation to a make target by declaring it like this: include help-system.mk all: $(call print-help,all,Builds everything) # commands go ...


2

This is a minor point, but you should declare all non-file targets as phony. Otherwise make will behave strangely if you have a file named named "all", "clean" etc in your directory. make will only run the command when the file is updated, which is not the desired behaviour. .PHONY: all clean mrproper help See What is the purpose of .PHONY in a Makefile? ...


2

You have many more .PHONY targets than just clean: all, check, debug, testbenches, run_test_script, createdir, maincpp. The maincpp rule should be: $(OBJDIR)/main.o: main.cpp $(CC) $(CFLAGS) -c -o $@ $< The createdir action is @mkdir -p obj, but should be written as @mkdir -p $(OBJDIR). main: createdir $(OBJECTS) has an improper prerequisite ...


2

I have not divided up the header files into their .h and .c files because they are very small header files. I would advice against this. Dividing into header and source files is just something you do. If something deserves an own source file, it also deserves an own header file. If nothing else, future readers of your code will expect .h files to only ...


2

I don't know SASS, but this inline generation of dependencies has one big weakness: you read every source file, even if it hasn't changed, and even if it's irrelevant to the target being built. The usual approach to dependencies is to write them into files (usually named for the target filename stem with .d or .dep suffix). Dependency files usually ...


2

Traditionally, the make variable CC is used for the C compiler and CXX for the C++ compiler. I would recommend changing CC := g++ to CXX := g++ Similaly, CFLAGS is traditionally used for C compiler flags and CXXFLAGS is used for C++ compiler flags. I would recommend changing CCFLAGS := .... to CXXFLAGS := .... In the same vein, linker flags are ...


1

only runs a target if the output hasn't changed since last run Consider writing rules like this: %.pdf: %.md pandoc -o $@ $< For that to work, the current all: ... pdf would need to mention particular *.pdf files, perhaps by globbing: $(patsubst %.md,%.pdf,*.md)


1

In a clean rule, consider removing $(OBJECT_FILES) instead of src/*.o I don't see where LDFLAGS is ever used. I understand that you are not likely to edit include files; however, to be on a safe side you may want to add auto dependency generation: DEP_FILES = $(SOURCE_FILES:.cc=.d) %.d: %.cc $(CC) $(INCLUDES) $(CXXFLAGS) -MM -MT -o $@ $< -include $(...


1

Overview As I understand it, you want use GNU Make to do… content/part?/raster/bw/* — the ultimate goal content/part?/raster/col/* — a staging place before conversion to grayscale content/part?/raster/col-addborder/* — source files that need a border to be added while copying to col content/part?/raster/col-noborder/* — source files to be copied to col ...


Only top voted, non community-wiki answers of a minimum length are eligible