Tips for Making Copy of Eclipse CDT Projects Easier

Instead creating a new project from scratch, often it is simpler to copy an existing Eclipse CDT project, then change it and go on.  To copy-past the a project in Eclipse:

  1. Select the project in the Project Explorer View (CTRL-C on Windows)

    Copy of a project

    Copy of a project

  2. Then paste it in the Project Explorer View (CTRL-V on Windows), and I can specify the new name:

    Paste of Project

    Paste of Project

However, to make that process simpler, a few things have to be done right in the ‘source’ project first.

I’m using the ‘copy-paste’ project in my classes too, where students get a ‘master’ project they can use as a base, multiple times during the labs if necessary.

Linked Files and Folders

Eclipse copies all the files in the project folders. Linked files and folders (see “Link to Files and Folders in Eclipse“) in the project are still linked files and folders. So they will be shared between the original project and the copy one.

Usually I avoid linked files and folders, as they easily can be a source of problems. If using links, then make them project relative, but this means that the copied project needs to match this, or the linked location needs to be updated. If you want to have the

Linked Folder Location

Linked Folder Location

To make projects easy to copy, avoid any linked files or folders: have the source project ‘standalone’, means have the necessary files be physically present in the source project, and not outside.

Artifact Name

With the copied project getting a new name, make sure that the build output (artifact name) is not a hardcoded one. Use



Artifact Name

Artifact Name

That way, the output file for the new project is matching the new project name.

Refresh Policy

There is an old bug in Eclipse with the Refresh Policy (see “Eclipse Project ‘Refresh Policy’: Broken Incremental Build with External Make?“). Make sure that the resources shown in the ‘Refresh Policy’ is matching your project:

Matching Refresh Policy Folder

Matching Refresh Policy Folder

Build and Compiler Settings

The compiler/assembler/linker needs some path and file information. Do *not* use absolute paths like “C:\myProjects\…”. Instead, use the the Eclipse CDT project variable ${ProjDirPath} and have paths surrounded by double quotes (if your project is named ‘Copy of MyProject’ or similar).

Even better, use a relative path like


as shown below:

Project Path Settings

Project Path Settings

The ‘current directory’ of the build tools (at least for the GNU ARM Eclipse integration) is the build directory location:

Build Directory Location

Build Directory Location

Using “../Sources” not only makes things relative to the project, it shortens the command line length which avoids a common length problem (see “Solving the 8192 Character Command Line Limit on Windows“).

Oh, and if you have not noticed: I’m using the ‘Linux’ forward slashes in the paths:


instead of “..\Sources”, that way I keep things compatible between Windows and Linux/Mac :-).


As with the copy we got all the build things from the earlier project, it is a good idea to make a Project > Clean to get rid of that old stuff:

clean of project

clean of project

Now build the project, and it should (hopefully) build just fine.

Debug Launch Configurations

Now this is the most complicated part :-(.

To make sure the debug configurations get copied too, make sure they are stored as files in the projects (see “Sharing Debug Configuration with Eclipse“):

Shared Debug Configuartion

Shared Debug configuration

Now they get copied, but having the old names (remember: Eclipse just does the file copy, it has no clue about the content):

Copied Launch Configurations

Copied Launch Configurations

So one obvious step would be to rename the files matching the new project name. It is optional because Eclipse CDT only cares about the .launch file extension to recognize something as a debug launch configuration. However, if still the ‘old’ and ‘copied’ project are present in the workspace, renaming avoids confusion.

The new configurations show up, but they have the wrong project name and application file listed:

Launch Configurations

Launch Configurations

An easy way is to change them in the above dialog. Another way is to use a text editor or script file to change the following string attribute keys in the launch file:

<stringAttribute key="org.eclipse.cdt.launch.PROGRAM_NAME" value="application.elf"/>
<stringAttribute key="org.eclipse.cdt.launch.PROJECT_ATTR" value="ProjectName"/>
project and application name in launch file

project and application name in launch file


With following a few basic things, a copy of an existing Eclipse CDT project is not that hard. Make sure you are not using linked files and folders, that the build artifact and path names are not hard-coded, and things should be much easier. While I have used the NXP Kinetis Design Studio in above screenshots, things are very similar to other Eclipse distributions too.

Happy Copying 🙂


7 thoughts on “Tips for Making Copy of Eclipse CDT Projects Easier

  1. The last time I used the Export feature it recreated the project but also de-linked the linked files and made local copies. This export feature could be usefull in creating archives.
    Preserving a project so that it could be recompiled 10 years later would be a challenge.


    • Hi Chad,
      yes, I always prefer ‘standalone’ projects. I don’t understand why the Kinetis SDK is using linked files and folders, it just makes it very hard to use the project for my own ones. And thanks for the tip about File > Export > Archive File file solution: I did not realize that it copies the files and not the links :-). Still it would be necessary to update the compiler/etc search paths, but that’s way better than doing it manually.
      We have projects where we indeed gurantee to build and maintain it for 10 years. For this we put away the notebook which is used to build it, because that’s the only way to preserve the whole environment and machinie settings.
      To use virtual machines could be a solution, but who knows if that virtual machine will still run in 10 years?

      Liked by 1 person

  2. Hi Erich,
    You forgot to mention that one needs to update the ‘refresh policy’ under the C/C++ Build property. If you forget this step you will be compiling every file every time because it is using the old project to find the dependencies.



What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.