Dependencies: right now your makefile will let changes in .h to remain unnoticed.
DEPS := $(SOURCES:.c=.d)
$(CC) -o $< -MM $(CFLAGS)
PS: it is highly recommended to remove -c from CFLAGS and mention it explicitly in the .c.o rule.
Not to be too blunt; but, you're going about this the wrong way. Look into the command line option -MMD for GCC, specify it when compiling your source; and, retain the inclusion statement for dependencies.
Also, no need for a default target. The first target is the default target.
Gpp = g++
srcs = $(wildcard *.cpp)
objs = $(srcs:.cpp=.o)
The C++ compiler is named CXX
What you call RESULT is usually named TARGET
In addition to SRC you probably need OBJ
Commands are usually replaced by uppercase version varaiable names that name themselves.
ie. RM not DEL
It rebuilds everything every time for two reasons.
The all: rule performs a clean: before it starts. ...
I would make source file discovery dynamic:
SOURCES = $(wildcard *.c)
In addition to all I usually add debug and release versions.
CFLAGS = -fdiagnostics-color=always -std=gnu11 -s -c -time
all: CFLAGS += -DTYPE=ALL
debug: CFLAGS += -DTYPE=DEBUG -g3
release: CFLAGS += -DTYPE=RELEASE -O3
I have a generic build file that I have all my rules ...
The first rule should just be
In turn, $(EXECUTABLE) will require $(OBJECTS), and each object will require its corresponding .c file.
Also, all should be a .PHONY target, since you are not actually going to produce a file named all.
Both of the remarks above apply equally to the debug target as well.
Things you did well
You initialize your variables when you declared them.
You initialize variables inside of your for loops.(C99)
Your pointer arithmetic looks pretty sound.
Things you can improve
Unfortunately, bubble sort is not a very good sorting algorithm if you are looking for speed. Its average case performance is \$ O\left(n^...
You are not using the make system properly. As a result, it will always relink the executable, even when everything is already up to date. On the other hand, it might fail to recompile some source files into object files.
When you run make…
It will try to create the build target. No file named build exists, so…
It will try to create the prerequisites ...
My CMake-fu is a bit rusty - probably as old as this question -, but I still see some things that could be trivially improved:
CMake doesn't require else() and endif() to contain the original if() expression anymore. It seems that this restriction disappeared a long time ago, so you can simplify your code by leaving empty else() and endif() expressions. ...
That will likely generate deps all the time, even if your target is 'clean'.
Put the dep targets and includes in an ifeq block which checks the makefile target, then there wont be any dependency generation prior to cleaning (since those files should be removed by the clean, it is a waste to generate them prior to clean).
# doing ...
First of all, good for you for learning how to write a proper makefile. Few people are any good at it, and it's a really fundamental tool. Even when nice tools such as CMake are used, it's very useful to understand how to write one from scratch.
With that said, here are some things that may help you improve your makefile:
Prefer Makefile to makefile
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 ...
I'll assume throughout this answer that you're targeting GNU Make. It's available on all targets that matter, and it simplifies your world no end if you can avoid pandering to the idiosyncrasies of the manifold implementations of Make supplied with operating systems.
Object files depend on headers
This is the biggest thing that I think could be improved; ...
The biggest problem I can see is that you are not using idiomatic Makefile names, which will confuse readers and frustrate users who want to change things via the command line. Typically CFLAGS is compiler flags passed to the C compiler, CPPFLAGS the preprocessor and CXXFLAGS the C++ compiler. $(CPP), $(I) and $(L) are are also just plain confusing and hard ...
Couple of things you do that don't match standards.
CXX is usually the C++ compiler
CC is usually the C compiler.
CXXFLAGS are the flags that are applied to the C++ compiler.
CPPFLAGS are the flags that are applied for the pre-processor.
This usually means passed to both C and C++ compiler.
CFLAGS are the flags passed to the C compiler.
I am the author of FASTBuild.
I presume the config as you have it is ok, but you're worried about copying it 95 times for your other projects and it becoming unmaintainable.
With that in mind, the best advice I can offer is to continue to factorize the common configuration patterns into structures (as you've already started doing). In particular, it looks ...
Your OBJ* variables are unnecessary, as they are just the executable name with a .o extension. You can simplify by doing something like this:
$(PROG1) : $@.o $(OBJ3)
$(LD) $^ -o $@
$@ expands to the name of the recipe's target, and $^ expands to the list of prerequisites. Note that this also replaces PROG3 with OBJ3, since that's what is actually ...
CXX = g++
# Notice the +=. Use CPPFLAGS rather than INC for pre-processor rules.
CPPFLAGS += -Iinclude/ -I../tools/
CXXFLAGS += -std=c++0x
# Move the backslash
# This will stop it looking like a directory at first glance.
CFLAGS traditionally refer to compiling .c files. The c++ compiler is traditionally invoked with CXXFLAGS.
I must advise against automatic collection of SOURCES (line 54). Usually you need to build more than one target from the same tree (a unit test version, for example). It is better to be explicit telling which sources contribute to which target.
Line 67. ...
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 ...
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) -e '$(HELP_FUN)' $(MAKEFILE_LIST)
Allow multiword category tags
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,$(...
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 ...
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 ...
In makefiles you can have spacing around equals signs, making the code slightly easier to read. For example PREFIX = ./node_modules/.bin.
UPPER_CASE variables are generally used for things that the end user might want to change when running, while lower_case is for internal use variables. The user is presumably not supposed to change for example the source ...
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 ...
The dependencies of gcd.h and test.h are missing. If you modify them, the objects would not be rebuilt.
Stem rules let you avoid repetition:
gcc -c $< -o $@
is the (almost) only thing you need to generate all objects.
Almost, because you'd still need to add .h dependencies. gcc has a nice feature to autogenerate them:
First of all, I don't know FASTBuild but it looks a lot like a Makefile, though I'm not an expert of that either.
The only redundancy I see is duplication in these and similar definitions:
.ForceUsingCommon = ' /FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll"'
+ ' /FU"C:\Program ...