Showing results for 
Search instead for 
Did you mean: 

ModusToolbox Blog


Sharing My Eclipse Project

When in the course of a developer’s life it becomes necessary to share a project, an Eclipse IDE (and ModusToolbox IDE is no exception) is both helpful and confusing. The use case we’re talking about here is: “I want to pack up my project and send it to someone for them to see, use, or comment on.” A perfect example is when you have a support question and the support engineer asks you to send them the project.

Here’s how.

Before we get started....

  • Pro Tip #1: Before archiving, select the projects in the project explorer. Then they are automatically selected for the archive.
  • Pro Tip #2: When you archive a project, do not include the Debug folder. The IDE regenerates this information, you don’t need to include it. You will save many, many megabytes of space excluding the Debug folder.

To send someone your project, you create a project archive. Use File > Export and then choose General > Archive file. In the resulting dialog, you’ll see your projects and all their elements. Select the project you want to include. Expand it to see all the “stuff” in the project, and deselect the Debug folder. Browse to where you want it to be, give it a name, and click Finish.


Now, how about the other side of this equation. Someone sent you an archive. How do I get it into the IDE? This is where Eclipse is confusing.

To import projects from the file system, use File > Import and then General. See the screenshot below. There are several wizards to choose from, one of which is called Archive File. Hey, I just created an archive file, so that’s what I should import it, right? WRONG! Silly you for being that logical.  


Instead, use Existing Projects into Workspace. Your archive includes an existing project. So you are importing the existing project.

For Existing Projects into Workspace, you specify that this is an archive file. Browse to it and click Finish.


Finally, as an aside, this and many other Eclipse oddities are discussed in my Eclipse Survival Guide. If you're new to Eclipse, you may want to check it out.  Happy Eclipsing!

Contributor II


Are there updates to the Export / Import concept for ModusToolbox (MTB) 2.0 related to the WICED devices?

I created a project in MTB 2.0, ran it successfully, then Exported it several different ways following various methods found in the community.

I attempted various methods of importing the various exported projects and files I created. They all fail to execute, most often producing errors related to wiced_btsdk if I try to clean or build...

11:07:43 **** Clean-only build of configuration Debug for project MTW20_q02_Try_this.empty_wiced_bt ****

"C:\\Users\\a73744\\ModusToolbox\\tools_2.0\\modus-shell\\bin\\make" CY_MAKE_IDE=eclipse CY_IDE_TOOLS_DIR=C:/Users/a73744/ModusToolbox/tools_2.0 -j8 clean

makefile:205: BTSDK application projects require the wiced_btsdk project as a prerequisite.

makefile:206: Please create the wiced_btsdk project via New Application wizard in the IDE or via git clone for CLI.

makefile:207: *** Missing prerequisite wiced_btsdk project.  Stop.

"C:/Users/a73744/ModusToolbox/tools_2.0/modus-shell/bin/make CY_MAKE_IDE=eclipse CY_IDE_TOOLS_DIR=C:/Users/a73744/ModusToolbox/tools_2.0 -j8 clean" terminated with exit code 2. Build might be incomplete.

11:07:43 Build Failed. 3 errors, 0 warnings. (took 247ms)

For most cases, I loaded the New Application wiced_btsdk before importing. I also tried loading the wiced_btsdk after importing. I get similar errors.

My ultimate goal is to create a working WICED project in MTB 2.0 that I can export so other people can import.

I emphasize "WICED" here as I don't think this is an issue with PSoC 6 based projects, that don't require the wiced_btsdk process before anything else.



Hi Greg! Here's hoping that the holiday was good, and that I can help. Looks like you already know as much if not more than I do.

For the benefit of others reading the thread...

On the MCU side, projects are entirely self contained. So exporting, not a problem. But the BT SDK is giving you conniptions in ModusToolbox 2.0

What you see in the application creation process, you have to create the "wiced_btsdk" first, and then create an application that uses it. The example application points to the BT SDK as a separate library. The name can't change, and it must be in the same workspace.

What that means when you export your application project that uses the BT SDK,  the BT SDK does not go along with it. So of course it fails. In principle, if the user creates the BT SDK and then imports your project into the same workspace, it SHOULD work.

I say in principle because I have not myself done that. It looks like you have, and it still fails. It looks like you have done that.

For most cases, I loaded the New Application wiced_btsdk before importing. I also tried loading the wiced_btsdk after importing. I get similar errors.

So I'll go play and see what I experience. That's what I want to replicate. There may be an Eclipse project dependency that has to be set up... I do have a couple of things I want to play with, but I have to play to learn.



OK, I think we have this nailed. Every application has a makefile. For the BTSDK examples, which point to the shared library wiced_btsdk, there is a line in the makefile like this:


This is a relative path to the shared library. The relationship of the application to the wiced_btsdk folder is what's critical here. Because the makefile has that hard coded.

Now, for the complications. There are some BTSDK examples that are a single app. Motion Sensor is one. If you export and import MotionSensor, everything works as expected.

Other BTSDK examples come in groups. When you use the IDE to create a new application, you end up with a bunch of them. They all show up at the top level of the IDE project explorer, but they are really in a folder hierarchy. Example the BLE beacon example is here relative to the wiced_btsdk



And it's makefile says...


When you export and import that example using Eclipse, that folder hierarchy is lost, you end up with



But the makefile still points to wiced_btsdk being three levels up the chain. So it breaks.

So, how do we fix this. When working with a "group" of examples like this, there are at least three ways you can solve this problem. I have them in my personal order of preference, but whatever works for you. In these instructions, I talk about a "group" folder. An example is


Zip this up, give it to the user, and they unzip it.

1: Use the IDE's import mechanism.

Click Create Application in the IDE. In the dialog, click Import, point to the group folder, and click Select Folder. All the projects in that folder appear in the IDE, and the relationships to the wiced_btsdk are maintained.


2: Put the group folder in the workspace, and then import using the Eclipse import mechanism.

Put it into the workspace. Like this


THEN, import existing projects into workspace, and choose the root directory in the workspace. Since it's already IN the workspace, make sure you don't copy the files into the workspace. This gets you the one project, and maintains the relationship to the wiced_btsdk folder.


3. After importing the "normal" way, which flattens the heirarchy, edit the makefile.





Or whatever the actual relative path is.

Honored Contributor II


Thank you for posting this.

Actually I was already aware of all the issues you mentioned.  I get rid of the entire "build" folder since MTB will rebuild it.

However, even after removing the "build" folder, the Zipped contents on a small project ("Hello_World") is still 21 MB!.  Unzipped the project is 78.4 MB!

I can remove the multiple "docs" folders.  They're only used for PDL references an other html parsing.  In fact there are some Java script files that can get as large as 1MB in the html folders!   For example:  In an archive of just one project (with three TARGET BSPs) there are 10 "jquery.js" files about 170KB each. REALLY?!

If I remove the "docs" folder and its contents the Unzipped size is now 38.5 MB.  Still large.  Zipped: 6.1MB.

When I created a PSoC Creator project with "Hello_World" is was about 28KB with minimum archiving. 

You would think that Eclipse (or Cypress) would have created a Archive script/utility like they have in PSoC Creator where you can specify the minimum archiving needed to preserve project integrity.

I don't know about you but every time I load a new project or get projects from others under MTB it eats up disk space.

Personally a lot of the common shared code is copied for EACH BSP loaded.  Wouldn't it be better to reference to a common directory location.  This includes the PDL references which alway exist on the web.  Even if a local version is desired, it should be copied to a common disk location and then referenced in the project files.

Using this method a Archive script/utility can gather these extraneous elements for the archive (Full archive) or indirectly reference these elements into the new user's common directories (Minimum archive).

Just a Thought.



Len, thanks! Excellent comments and insight. What you're seeing is a direct side effect of design decisions in how a project is put together in ModusToolbox. Like any such, there are tradeoffs. Our primary design goal is to ensure that a project works. 

To maximize the chance a project works, we eliminated external references (e.g. to a local copy of PDL stashed somewhere). Instead, every required library is locally copied into every project. End result of this choice? Let's call it project bloat. Every project has its own copy of everything. But, it WILL work! There are no problems with broken paths, references to something that moved, or that you have installed in some non-default location, or that doesn't exist. The issue of "project bloat" is one we debated internally at length. We opted for Works Reliably. 

There are "things" you can do to manage this, and you outlined several. If you're familiar with GitHub, see a KBA I just published...How to Share a ModusToolbox Project via GitHub. That has some insight into what matters and what doesn't when sharing a project.

The biggest impact you can have is to not include the libraries when you archive/share a project. Like the PDL or the BSP. In ModusToolbox 2.x, all you need is the .lib files. The default .gitignore file we now provide for GitHub users does that - excludes all those shared libraries. But the user needs to know to execute make getlibs to pull in all the libraries from GitHub. That's covered in the KBA. Once they do, then THEIR project is filled with local copies of all the libraries, and they have a "bloated" project. But what you share is a LOT sleeker.

The ModusToolbox build system relies on .lib files and locally copied libraries. It is absolutely possible to remove those, add paths to and include files from your personal local source code collection. So multiple projects can use the same PDL for example. You can set that up. In fact, for most serious users, I suspect in the end that's what they'll do. OK, now that I know what we need... we'll get these versions of these libraries, stash them on our server here, and all of our projects will point to our local shared stash. Besides, who wants the overhead of downloading megabyte after megabyte of source code from GitHub every time we create a project.

But we don't do that. Because then... projects break, paths are wrong, etc etc.

Let me know if there's any other question. I love feedback!

Honored Contributor II


Thank you for your feedback.


Is it possible to create a archiving utility that can be launched from MTB where it uses the .gitignore file you spoke of to create a "minimized" arc?



Hey Leonard! We already have an internal ticket tracking “project sharing” improvements for ModusToolbox 2.2. I will raise the issue. No promises about it actually getting done, since it gets in line with lots of other stuff. But the idea that we should have some way to create a “clean” archive without having to understand what’s safe to leave out, I’m on board with that.

About the Author
Been there, done that. Mostly. For software tools and developer support.
Top labels