Dependencies not generated properly

I’ve been chasing a bug for the last hour or so and found something very bad. I have a very large project with loads of header files and loads of source files that include those header files. I just noticed that when I change a header file in my project it doesn’t rebuild all the source files that include the header files!!!

Has anyone else seen this? It appears that I have to do a “clean” build every time I change a header file. To me, this is a showstopper bug for any build environment.

yes, I’ve also stumbled across this.
changed an enum, but this was not reflected in .c files that included this .h file

Yes, I’ve also seent it! :angry:

See also: viewtopic.php?f=78&t=4307&p=17212#p17212

Please can you elaborate on the use case?
Seems working when all concerned files are part of the same project. Are you including files outside of the workspace, or from another project location?
Please can you provide a concrete (and if possible small) example project reproducing the issue, to let us investigate.

This post tells you how I have my project setup:


I have hundreds of file, many of which include many of the same header files. If I change a header file then I expect ALL source files which include the header file to be rebuilt. Instead, it appears that it will rebuilt one source file, which include the changed header file, but not all of them. I havn’t been able to figure out the reason why certain source files are rebuilt but not ALL of the others. In one case I have a “configuration.h” header file that is included in ALL of my source files. If I changed it, only one file is rebuilt.

I can’t exactly send you my whole project but if I you want to get in touch with me through the US FAE out of RTP I would be more than glad to setup a net meeting and show you my build environment and reproduce this problem for you.


We will take time to investigate on the issue, and come back to you if we get a workaround.

the workaround is simple…
just do a ‘clean project’ if you changed a headerfile

Yes, that’s what I do.

But that is really just an admission that build system is broken :exclamation: :angry:

If you’re going to have to do a full “clean” build every time, there is no point in messing about with all this arcane makefile and dependency stuff - you might as well just have a simple batch file that just compiles each & every file every time.

Right now I always to a “clean” when I change the header file. Even with this system building faster, my project is so large it still takes many minutes to build my project from scratch. I see this as a temperary work around instead of a solution.

and that’s exactly how i meant it :slight_smile:

Is there any update on this? This behaviour is driving me crazy :exclamation:

As nobody has actually posted a clear example of how to reproduce this, I will do so now:

  1. Import the attached project to M2M studio.
  2. Build the project (it should build without errors or warnings).
  3. Comment out the line in HeaderTest.h.
  4. Save HeaderTest.h.
  5. Select “Build All” from the the “Project” menu.
  6. The last line of the console output will read “Nothing to build for HeaderTest”.
  7. Select “Clean…” from the “Project” menu.
  8. Make sure the project is selected, then click “OK”
  9. The build will fail because the macro used in HeaderTest.c is no longer defined. (11.1 KB)

Famous last words!

No, I get errors in “generated.c”, and when I click on one of those errors, M2MStudio throws up loads of errors and says that it can’t open the editor!

M2M Studio 1.1.1
Copyright (c) Sierra Wireless 2009
Build Version

Before uploading the zip file, I made sure that I could import the project without problems. However, today I get the same problem that you describe. In fact it goes deeper than that, so I’m going to create a new thread for this problem.

However, back to the topic at hand. As importing the previously attached project doesn’t work well, here are some revised steps:

  1. Create a new project in M2M studio, using the default settings.
  2. Copy main.c from the attached zip file to the src directory.
  3. Copy HeaderTest.h from the attached zip file to the inc directory.
  4. Refresh the project.
  5. Build the project with Project->Build All.
  6. In theory, the project should now compile without errors. However, if this is not the case, fix any errors before continuing.
  7. Comment out the line in HeaderTest.h.
  8. Save HeaderTest.h.
  9. Select “Build All” from the the “Project” menu.
  10. The last line of the console output will read “Nothing to build for ”.
  11. Select “Clean…” from the “Project” menu.
  12. Make sure the project is selected, then click “OK”
  13. The build will fail because the macro used in main.c is no longer defined. (419 Bytes)

See: Problems importing projects

I’ll give it a go sometime today…


1.1.2 has now been released. The problem still exists. Can we at least get official confirmation that this bug has been reproduced by Sierra Wireless? A target date/version for a fix would also be nice.

As far as I am concerned, this bug falls just short of critical. If you can’t trust your build system, how can you trust your application?


I can confirm it. The 1.1.1 and the 1.1.2 has this bug. I will make a clean install on a maschine that has never seen M2MStudio, sorry no… Develeper Studio ( yeah another name change just to confuse everybody ) and start the ExternalStorage_IIC sample just to check it. But if i understand well, the package installer does not leave entries in registry or anywhere else and if we are using different workspaces it shouldn’t be a problem.

I made a clean install. Installed to defaults. Not changed anything in options. The bug is still there just trying with ExternalStorage_IIC sample.

Please can you (tomalex?) confirm that the issue is not present in 1.1.0?

We are indeed reproducing the issue, and posted an entry on Eclipse CDT side:
Don’t hesitate to vote!

I can confirm it. The issue is not present in 1.1.0. I have just rechecked it with ExternalStorage_IIC sample.

After investigations and tests, it appears that the bug seems to be fixed in a more recent Eclipse CDT version (6.0.2; Developer Studio 1.1.2 currently includes CDT 6.0.1).

We are preparing a new 1.1.2 build based on this version, and will make it available as a release candidate ASAP. We will communicate this release’s update URL when it will be available.