As I'm new to MCUXpresso, I found this compiler behaviour rather disconcerting so thought to throw it to the community for reassurance.
I have been using a FRDM-KW41Z board and have not tested to see if this applies to other boards.
I noticed these two links are always included (in paths and symbols within includes in C/C++ general properties) in new projects or if I import an SDK project.
I was porting code from another project and editing this code in a new project and kept noticing that these two links disappeared after a while and could not fathom why.
So I carefully reconstructed and discovered that these two links disappear from my project as soon as I run a build and it fails.
So I am wondering if this normal behaviour?
I thought to change my earlier choice of a Correct Answer, as whilst it did solve a particular case, and is the correct way to manually add new includes into a project, it actually did not solve the problem related to those two missing links as I found another scenario that is related.
This case is rather strange and it took a good while to figure out.
If I create a new project with say an FRDM-KL25Z board or others and then create a new project with an FRDM-KW41Z board then all includes for all project are resolved and everything links ok.
If I then exit from MCUXpresso and then reopen the IDE and go to say my new FRDM-KW41Z project or any of the other projects I had created) it shows the following (links are now missing):
To confirm this, I can then choose Project... C/C++ Index... Search for Unresolved Includes, and this menu option will then pick up <stdio.h> for you.
This occurs for both c and c++ projects.
MCUXpresso support has identified the issue and said that while there's no present workaround, there should be a fix in the next MCUXpresso release, expected by the end of 2019 Q2. See the end of this thread.
To follow up on this thread:
The IDE V11.0.0 (and later) have a context menu item (right click on the project main folder) which fixes the parser for any projects which expose this issue:
Tools > Fixup Parsers
I hope this helps,
Erich
An update...
I decided to pay attention to the message that's given below the includes box "Using relative paths is ambiguous and not recommended (my comment - then why provide this as default!!). It can cause unexpected effects."
I then had to manually change all include directories by ticking the "Is a workspace path".
I noticed a difference between some examples I've worked through. When I simply tick that option it inserts the actual path directory name.
However many other working demos use this macro/shortcut function "/${ProjName}" and then when clicking that option the "/${ProjName}" is always used, as follows:
I noted that there is now a new message given "Preprocessor Include Paths...."
This worked (I think) as even though my build occasionally failed I did not lose those other two links.
HOWEVER...
I then decided to change the project name (using the rename option) for my project.
When I did that I lost those two links again.
I have used MCUXpresso and its predecessors for nearly 10 years, and I have NEVER used that particular setting for include paths (as far as I know, it is 'discovered' by the IDE when doing a build - that is output by the compiler). The correct way to specify include paths is to add them in the MCU C Compiler, "Includes" section of the project properties. See image.
Hi Colin,
I saw something similar a few days ago and reported this to the IDE team. They are investigating this.
If you don't have these paths in the list, it basically means that the Eclipse Indexer (F3 or jump to declaration/definition) won't be able to find things like stdio.h. Other than that, it should not affect you negatively.
Otherwise add the two paths in the 'Path and Symbols' list again.
I hope this helps,
Erich