LPCXpresso 7.1.1 (build 125) compiler creates incorrect dependency files leading to incorrect incremental builds

[lpcware]

Content originally posted in LPCWare by OldManVimes on Sat May 17 09:54:54 MST 2014
Hello support,

I recently started noticing that incremental compilation no longer worked flawlessly for my project. I've looked into this and notice a difference between the generated dependency files of the LPCXpresso project and a generic non Xpresso Eclipse project using GCC + GNU make. Host system is Windows 8.1

What I get in a .d file is:
src/main.d: ../src/main.c \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/LPC17xx.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/core_cm3.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/core_cmInstr.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/core_cmFunc.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/system_LPC17xx.h

What I expect is:
src/main.d src/main.o: ../src/main.c \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/LPC17xx.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/core_cm3.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/core_cmInstr.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/core_cmFunc.h \
C:\Users\me\Documents\LPCXpresso_7.1.1_125\workspace\CMSIS_CORE_LPC17xx\inc/system_LPC17xx.h

By adding the .o file as a target, GNU make will recompile main.c if any of the .h files changes. Without it, that does not happen (as far as I can tell).

Since the dependency files are generated by the GCC compiler, I suspect the issue lies there. I've compared the way the compiler is invoked in a regular Eclipse GCC project and in LPCXpresso and can't find any difference related to dependency generation flags.

What is generated (different context, so ignore LPC12xx vs. LPC17cc) is:
arm-none-eabi-gcc -D__REDLIB__ -DNDEBUG -D__CODE_RED -DCORE_M0 -D__USE_ROMDIVIDE -D__USE_CMSIS=CMSIS_CORE_LPC12xx -D__LPC12XX__ -DCR_INTEGER_PRINTF <stuff removed> -Os -g -Wall -Werror -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m0 -mthumb -D__REDLIB__ -specs=redlib.specs -MMD -MP -MF"$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -o "$@" "$<"


You should be able to reproduce this simply by creating a sample project in LPCXpresso and compiling it. If the dependency files looks as the first example, you can get incremental builds to fail. So just change a character in core_cm3.h and observe that an incremental build does not trigger an update for main.o

Any ideas?

[lpcware]

Content originally posted in LPCWare by daschuer on Wed Jun 04 08:24:45 MST 2014

Hi Support, Hi OldMan,

---

Quote: OldManVimes
If anyone runs into this issue and then spends a lot of time not understanding what's going on, and then finds this thread, some, few or more expletives will be uttered. You are in a position to prevent that.

---

I was exacactly in the same situation. It took me a day to find out what was going on and find the right search phrase to find this thread. 
"make --debug=m" was my firend.

Since this seams to be not at high priority, you may put
"no rebuild when header change" into the thread title.

Thank you!

[lpcware]

Content originally posted in LPCWare by OldManVimes on Mon May 19 05:54:29 MST 2014
Hi Support,

Thanks for the reference to the Eclipse bug report. Also, I understand this is not an issue created by LPCXpresso. The fact that this problem has existed for as long as it has is mind boggling (in my head I use different words to describe this). Why should anyone have to deal with this situation? As far as I'm concerned, the CDT team needs a sanity check.

The likelihood of running into this issue is.... debatable. If I change a constant in a header file and then do a compile + debug, my code runs without that change since any dependent .c file is not recompiled. Try explaining that to a beginner or an overworked software engineer who just expects very basic infrastructure that has worked well for 30-40 years to work flawlessly. The only reason I found out is because I use a script at compile-time to generate a build number in a .h file and was puzzled by the fact that this constant did not end up in my binary until I did a rebuild.

Any generic remedial fix that you can add to LPCXpresso until the CDT team finds time in their schedule to fix this is still appreciated. I won't need it, since I will use the workaround (which works by the way) . However I'm sure others who experience 'weird behavior' until they perform a clean build will appreciate it, even if they never know they had this issue. If anyone runs into this issue and then spends a lot of time not understanding what's going on, and then finds this thread, some, few or more expletives will be uttered. You are in a position to prevent that.

[lpcware]

Content originally posted in LPCWare by starblue on Mon May 19 04:51:08 MST 2014

---

Quote: lpcxpresso-support
-MT"$(@:%.o=%.o)"

---

The ":%.o=%.o" part is redundant, it replaces a .o suffix with itself,
see https://www.gnu.org/software/make/manual/make.html#Substitution-Refs .

So the correct thing to do is IMHO to just add -MT"$@".

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon May 19 04:16:23 MST 2014
The behavior has been in LPCXpresso since LPCXpresso 5 (at least - I haven't checked earlier releases). You are the first person to have raised it, and therefore I do not agree that it is a serious bug.

I suggest you may want to comment on the existing Eclipse bug report to see if you can raise the priority of this being addressed by the CDT development team.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=391735

[lpcware]

Content originally posted in LPCWare by OldManVimes on Mon May 19 04:04:11 MST 2014
Hello support,

Thanks for the tip. I will use this as a temporary solution. The problem is that some of these flags are always generated, and that is likely to be part of the problem. I suspect we are in agreement that this issue should be addressed in the toolset by default. Makefile structure is not common knowledge and having non-dependable incremental builds creates problems for everyone. I suspect a generic current Eclipse/CDT/Cross compilation project will produce a proper set of dependency related compiler flags that LPCXpresso can adopt, but I haven't looked into that. It is possible that simply removing the existing non-optional -MT flag solves the issue, but I'm guessing at this point.

Do you agree this is a (rather serious) bug? Will you look into this for a future version of LPCXpresso?

[lpcware]

Content originally posted in LPCWare by starblue on Mon May 19 02:57:22 MST 2014
The -MT option tells gcc to generate only the .d dependency.

See https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon May 19 02:29:00 MST 2014
I can reproduce your behavior (i.e. the missing .o dependency in the .d file) with ANY version of GCC 4.8 - both arm-none-eabi-gcc and gcc. (I have tried gcc in Ubuntu 14.04 as well as the version supplied in the latest version of mingw on Windows).

The change seems to have been made sometime between GCC 4.5.2 and GCC 4.6 - i.e. a long time ago.
I haven't been able to track the reason for this change, but as it seems to be in the GCC baseline for a long time, I assume it was done to fix a specific problem.

*EDIT*
However, I have found a workaround

In each project, I go to:
properties -> C/C++ Build -> Settings -> Tool Settings -> Miscellaneous of compiler -> Other flags
Then add to the flags:

-MT"$(@:%.o=%.o)"