unresolved inclusions in Eclipse

[Tosa]

I'm using nRF52 + SDK11.0.0 + s132. I'm following this tutorial. I am able to build from the command line and from Eclipse just successfully. However, Eclipse is unable to properly decode the include paths. It is properly decoding the defines. 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?

The headers that are in the same directory as main.c seem to be resolved successfully:

I'm using the makefile from the tutorial (modified for my files). It has 'abspath' in it for each of the include paths. Is this a cause of the issue? How can I resolve the unresolved inclusions?

I also tried the blinky_blank example for the same SDK (downloaded the Eclipse project from the tutorial) and I get similar unresolved inclusions. However, when I right click on main.c in this project, I'm not allowed to see the defines or includes:

My blink_blank project is attached here armgcc.7z

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

[Vidar Berg]

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.

[Tosa]

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?

[Vidar Berg]

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.

[Tosa]

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?

[Vidar Berg]

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.