unresolved inclusions in Eclipse

RE: unresolved inclusions in Eclipse

Vidar Berg — Thu, 16 Feb 2017 08:15:17 GMT

Eclipse managed projects provide closer integration since it will maintain its makefiles automatically. Also, with make managed you will sometimes have to refresh the index manually to fix unresolved symbols ( or restart eclipse). I think the main advantage with make managed projects is that you can re-use existing makefiles which are maintained by the SDK team, but I don't see any major drawbacks with either of them.

RE: unresolved inclusions in Eclipse

Tosa — Wed, 15 Feb 2017 15:34:47 GMT

Thanks for the clarifications. I got the incremental build Standard Make and also separately a Managed Make Eclipse project working. The Managed Make project doesn't seem to be too much more work than the Standard Make project (assuming the flags and linker scripts are all provided). And it seems more tightly integrated with the code (so the unresolved inclusions issues doesn't seem to appear at all; it still seems to appear with the Standard Make project and I need to restart Eclipse to make it work). Do you seen any downfall to the Managed Make projects?

RE: unresolved inclusions in Eclipse

Vidar Berg — Wed, 15 Feb 2017 09:31:48 GMT

project makefiles in SDK 11 were standalone. I.e., not invoking makefile.common as opposed to project makefiles in SDK 12. I think the easiest approach is to import the makefile.common from SDK 12.2.0, and one of the project makefiles that resembles your existing makefile the most(makefile located in project directory). Then modify the project makefile according to your existing makefile (update list of source files, include paths, and flags (CFLAGS, LDFLAGS, ASMFLAGS)).

We changed to C99 to use the same standard on all the toolchains we support. __ASM/__asm() are more portable.

RE: unresolved inclusions in Eclipse

Tosa — Tue, 14 Feb 2017 19:18:02 GMT

In SDK11.0.0, it seems that Makefile.common is not used but Makefile (in the project dir) and Makefile.Windows (or .Posix) are used, correct? In SDK12.x.x, the project Makefile (project dir), Makefile.Windows and Makefile.common are all used correct? Also, the Makefile.common in SDK12.2.0 is much different from the SDK12.1.0 version. Should I back port the SDK12.2.0 version?

Also, the compiler standard is switched to c99 vs gnu99 so the asm() calls don't work unless replaced by __asm() (or I modify Makefile.common to use gnu99 rather than c99). Any reason for the switch?

RE: unresolved inclusions in Eclipse

Vidar Berg — Mon, 06 Feb 2017 11:23:33 GMT

The following screen shot of the main.c parsing shows that the header path starts with /g rather that g:/. I am wondering if this is the issue?

I think this is the problem, but not sure exactly why it happens. I'd suggest to make sure you are only invoking the build tools from the GNU ARM Eclipse Windows Build Tools package. I.e., check that aren't any other installations of make.exe, sh.exe, etc on your system, and if it is, try to remove any paths for those in your PATH variable.

Separately, is there an example makefile for SDK11.0.0+s132 that does incremental builds?

You can back port the makefiles from SDK 12 if you want to support incremental builds.