make: Nothing to be done for ‘all’ – Eclipse Error Solved

I’ve seen this odd error several times over the years, almost always after first importing a new project into Eclipse-CDT.

After import, when you try to build your project, it just returns the message make: Nothing to be done for all in the console.

And then, once you’ve got the error, nothing you do will kick your build into action – changing files, changing project settings, even deleting and recreating build configurations.

If you try to run the executable, you just get Launch failed. Binary not found.

Because, of course, make hasn’t built anything.

Aargh!

Annoying, eh?

Well, it turns out there is a simple reason for this problem, and it’s actually really easy to fix it.

You need to make sure that you never name your project (and thus your executable), and the sub-directory within that project that contains your source files, with the same name.

eclipse_project

The sub-directory here is usually called ‘src’, but only IF you built your project from the ground up within Eclipse. If you imported the files from elsewhere, it could have any name. And if you happen to use the same name as the project…

Well. Sad face, right?

The reason for this is the way in which Eclipse manages its build process with make.

You don’t need to understand the workings, but if you are interested, I’ve detailed the process below.

If you just want the solution, there are two things you can do:

1. Change the executable name

The name of the executable is actually the real issue here. If you want to keep your folders exactly as they are, you can change the executable name by right clicking Project and selecting Properties > C/C++ Build > Settings, and then under the tab Build Artifact, change the Artifact name field from ${ProjName} to something else, e.g. MyAwesomeProgram. After making the change, the project should build normally.

2. Change the sub-folder name

Alternatively, you can just change the subfolder name to something else. The default for Eclipse projects is ‘src’, but you can use anything you like. As long as it isn’t the name of the project (and thus, by default the name of the executable too), you will be fine.

Er, but my source folder isn’t the same name as my project (and by default the project executable).

If you haven’t named your sub-directory with the same name as the project (and thus, the executable), Eclipse can often be prodded into cooperating by refreshing the modified date of the source files:

In a terminal, cd to the source directory of your project and type:

touch [any .c or .cpp source file name in your project]

e.g.

touch Coord.cpp

You should only need to do one file – this will update the file modified time and Eclipse should start rebuilding again.

If that still doesn’t work (and Eclipse may not rebuild properly if all you have edited is header files), you can update all the files with:

touch *

Touch updates the last modified time of the file it is passed (or all files if you use *). It doesn’t modify the files in any other way.

The Eclipse build process

Here’s a quick rundown of why the build fails and make thinks everything is up to date:

1. You create your project, let’s say it’s called maze.

2. You import some source files which you have in a folder called maze, and Eclipse uses this folder structure in the project.

3. Now, after the import, Eclipse has a folder structure like this:

1. Eclipse project folder – “maze”

2. Your source folder – “maze”

3. Eclipse Build Config folder – “Debug”

4. Build sub-folder (name generated from 2) – “maze”

5. Binary destination (name generated from 1) – “maze”

When you call make, in addition to the things that make does, Eclipse also updates any build sub folders (4), which changes their last modified time.

Make then looks for the binary (5), which it knows is called ‘maze’, but instead it sees the timestamp on the build folder (4), not the executable (5), which hasn’t been created yet.

Make concludes that the executable (which still hasn’t been built), is up to date because the timestamp (which has just been stamped) is more recent than all of your source files, including any that you edited and saved directly before the build command,  because Eclipse always updates the build folder after you have saved your changes ready to build.

Crazy eh?

It’s not even really a bug with Eclipse, I suppose, although it just goes to show that you can never anticipate how people are going to use your software, and no matter how much you test it, someone, somewhere will find a way to do something you never expected 😉