What is the point of Makefiles?

Started by
8 comments, last by Fiddler 13 years, 4 months ago
In pretty much any source package I've downloaded, there is a Makefile. I've looked at a few and they're big, bloated, and ugly to look at. I couldn't imagine writing one. Is there some advantage to them over compiling straight from the command line? The way I do it is this:

My project directory has a "bin" and "src" folder and a compile script for each operating system the source code supports. The compile script for Linux, for instance, would be something like this:
g++ -o ./bin/executable -lLibrary1 -lLibrary2 `ls ./src/*.cpp`

That simple 1-line script will compile every .cpp in the src folder with the specified libraries and spit out the executable into the bin folder. I don't really understand how a Makefile would be needed.

Any insight?
Advertisement
Quote:Original post by Chaosenemy
In pretty much any source package I've downloaded, there is a Makefile. I've looked at a few and they're big, bloated, and ugly to look at. I couldn't imagine writing one. Is there some advantage to them over compiling straight from the command line? The way I do it is this:

My project directory has a "bin" and "src" folder and a compile script for each operating system the source code supports. The compile script for Linux, for instance, would be something like this:
g++ -o ./bin/executable -lLibrary1 -lLibrary2 `ls ./src/*.cpp`

That simple 1-line script will compile every .cpp in the src folder with the specified libraries and spit out the executable into the bin folder. I don't really understand how a Makefile would be needed.

Any insight?
That command will recompile everything every time you run it no matter what. make checks the dependencies and only rebuilds things that are out of date.

What if you have some files you want excluded in the final build/only in debug builds? What if you need to do extra work like delete some intermediate files? What if some files need different preprocessing? What if you want to build multiple types binaries from your project based on different build parameters? And so on...

Of course your own makefiles don't need to be nearly as complex as the ones you downloaded, but as your projects grow you'll probably have your makefile become more and more complex as time goes on. But it may even be the case that the makefiles you downloaded are more complex than they need to be. Without knowing what they actually contain it is hard to say. If you learn how to read makefiles you can probably determine better whether your assumption held.

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

Thanks for the quick answer. I suppose I understand somewhat, but for the time being I guess I'm going to stick with my method. As it is, my current project only takes about 10 seconds to compile anyways.
Quote:Original post by Chaosenemy
Thanks for the quick answer. I suppose I understand somewhat, but for the time being I guess I'm going to stick with my method. As it is, my current project only takes about 10 seconds to compile anyways.


Alot of IDEs also generate makefiles for you based on your project settings, this means you don't really have to write them yourself.
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Understand that there is nothing fundamentally wrong with using your own build scripts. I use simple build scripts all the time because they are far less complex than makefiles, but as others have pointed out, makefiles have many advantages.
Amateurs practice until they do it right.Professionals practice until they never do it wrong.
Also, consider that make is just a big dependency tree walker. The rules don't have to relate to code at all. The rules just specify some output files and what they are dependent on. So, you can create makefiles to process your level data and other assests whenever they are updated.
One thing I tend to do (which might not be normal) is to place my unit tests directly into the makefiles so that they run after make is ran. They spit out errors if a change between builds breaks a test. Makes things more automatic.
Sometimes an application may make use of some library *only* if you have it installed in your OS. If you don't have it, configure and make can still let you compile the application without including the code that makes use of such library. Take for instance the different display libraries that SDL can use.
[size="2"]I like the Walrus best.
Quote:Original post by Sirisian
One thing I tend to do (which might not be normal) is to place my unit tests directly into the makefiles so that they run after make is ran. They spit out errors if a change between builds breaks a test. Makes things more automatic.

I often use a target "test" so that "make test" will run a bunch of diagnostics.
Makefiles suck. No, they really do, the syntax is awful and they start to break down as the project grows larger, to the point that many projects recommend a "make clean" before recompiling (at which point, you might as well "g++ *.cpp" and be done with it).

@Chaosenemy: check out cmake. It will handle your building tasks without sacrificing your sanity. It will also create project files for any IDE you might wish to use in the future, which rocks.

There's absolutely no reason to use makefiles on a new project.

[OpenTK: C# OpenGL 4.4, OpenGL ES 3.0 and OpenAL 1.1. Now with Linux/KMS support!]

This topic is closed to new replies.

Advertisement