Eclipse paths to nowhere...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DaveNadler on Fri Apr 08 14:35:49 MST 2011
[FONT=Arial]Hi - I've got a project running, but Eclipse is confused.

Background:
- I started with FreeRTOS demo project, works great.
- Made a copy for my own board, changed processor type, etc.
- Had to fix numerous paths Project>properties>C/C++ build>Settings>directories.

Example project had many paths hardwired to ${workspace_loc:/freeRTOS...
That obviously can't work as includes must be set for each specific project.
Changed to relative paths ../config and so forth.
Everything builds properly and works great.

Except... Eclipse keeps trying to do macro expansion,
display of include files, etc from the original hardwired
path. I *REMOVED* the original, again cleaned and rebuilt
and restarted Eclipse numerous times... but its still
messing up and using incorrect old cached values.
Deleted Debug/... build results tree, etc, etc...

How can I get it in sync with the actual build ?
Where for heavens sake has it squirreled away this info ?

Sincere thanks in advance for any help (this is quite maddening :mad:),
Best Regards, Dave
[/FONT][FONT=Arial]
[/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by OXO on Sun Apr 10 08:44:54 MST 2011
.. and this is the problem with Open Source.

When it goes wrong, there is nobody to complain to..

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Sun Apr 10 03:40:48 MST 2011

Quote:

(2) The CDT plug-in has cached incorrect information in the locations above. Unlike other Eclipse distributions, there does not seem to be a way to get CDT to rebuild everything from within the IDE...

LPCXpresso IDE *is* a standard CDT distribution (with some additional plugins). Therefore, anything that is possible in CDT is possible in LPCXpresso. The solution that worked for you is a well known and long standing CDT bug.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sat Apr 09 15:10:09 MST 2011

Quote: DaveNadler

(1b) Ooops, windows won't let you. Restart Windoze, blowing away any zombie LPCexpresso.exe :)

You probably didn't have to restart windows. I blow away the zombies from the task manager then restart LPCXpresso.

Hopefully zombies will be fixed in the next revision of LPCXpresso, especially zombie debugging sessions. CodeRed, look for the zombies and kill them for us please. The IDE delivers an error message but still leaves the process running.:confused:

Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DaveNadler on Sat Apr 09 14:47:12 MST 2011

Quote: CodeRedSupport
Where did you get the *original* project from?

the freertos example application

Quote: CodeRedSupport
Some things I noticed/advice:
- The core_cm0.c and system_LPC11xx.c files have the own build settings (in Project Explorer, they have little blue "<>" symbols in their icons). Try restoring them to the defaults (Right-click on the *file*, select Properties, open C/C++ Build/Settings and press Restore Defaults). This will mean they share the same build settings as the rest of the project

No idea how those got set. After resetting them and restarting Eclipse they finally went away. No change in behavior.

Quote: CodeRedSupport

- If that doesn't help, Look in C/C++ General/Paths and Symbols and remove any extraneous paths in there

No extraneous paths found...

Quote: CodeRedSupport

- If that still doesn't help, try this support article:
http://support.code-red-tech.com/CodeRedWiki/InvalidProjPath

Bingo. The magic answers to my two questions are:

(1a) Close eclipse, and delete the file(s) <your_workspace>/.metadata/.plugins/org.eclipse.cdt.make.core/<projectname>.sc
(1b) Ooops, windows won't let you. Restart Windoze, blowing away any zombie LPCexpresso.exe
(1c) OK, now really delete those files and restart Eclipse, CDT will rebuild the files, and things work properly (well, more or less).

(2) The CDT plug-in has cached incorrect information in the locations above. Unlike other Eclipse distributions, there does not seem to be a way to get CDT to rebuild everything from within the IDE...

Quote: CodeRedSupport

- Finally, try exporting your project(s) and then importing them into a new workspace.
If none of that helps, please describe *exactly* what I should do to reproduce your problem.

Hope that helps,

Thanks for the help !
Best Regards, Dave

PS: Please fix the hardwired paths in any examples, so that copying an example project behaves a bit more as expected :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by OXO on Sat Apr 09 13:17:42 MST 2011

Quote: DaveNadler
Nope, I did a copy/paste inside the project explorer. Then wasted some time tracking down why changing the configuration include files did not work (erroneous hardwired paths in the sample application pointed to the original H files rather than the copy, which I fixed as described earlier). I checked the .cproject and didn't see any references to the (now non-existant) freetros directory.

I've attached a zip of the workspace info I think required to reproduce the issue. In file system_LPC11xx.c, try looking at the macro expansion SYSOSC_SETUP. Eclipse shows a value of 1, but it is actually set to 0 in file system_LPC11x.h - also try open the definition from the C file and you get a blank window.

Again, the program compiles and operates properly, its just that Eclipse is snarled up.

Thanks in advance for any help here,
Best Regards, Dave

Hi Dave, nice to see my friends here :)

Chris

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Sat Apr 09 08:40:33 MST 2011
Where did you get the *original* project from?

Some things I noticed/advice:
- The core_cm0.c and system_LPC11xx.c files have the own build settings (in Project Explorer, they have little blue "<>" symbols in their icons). Try restoring them to the defaults (Right-click on the *file*, select Properties, open C/C++ Build/Settings and press Restore Defaults). This will mean they share the same build settings as the rest of the project
- If that doesn't help, Look in C/C++ General/Paths and Symbols and remove any extraneous paths in there
- If that still doesn't help, try this support article:
http://support.code-red-tech.com/CodeRedWiki/InvalidProjPath
- Finally, try exporting your project(s) and then importing them into a new workspace.

If none of that helps, please describe *exactly* what I should do to reproduce your problem.

Hope that helps,

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DaveNadler on Sat Apr 09 06:05:20 MST 2011

Quote: CodeRedSupport
How did you create the project that is causing your problems? My guess is that you did a copy/paste of a projects directory using Windows Explorer (the key point being your did it OUTSIDE of the IDE) and then renamed it and started Eclipse....

Nope, I did a copy/paste inside the project explorer. Then wasted some time tracking down why changing the configuration include files did not work (erroneous hardwired paths in the sample application pointed to the original H files rather than the copy, which I fixed as described earlier). I checked the .cproject and didn't see any references to the (now non-existant) freetros directory.

I've attached a zip of the workspace info I think required to reproduce the issue. In file system_LPC11xx.c, try looking at the macro expansion SYSOSC_SETUP. Eclipse shows a value of 1, but it is actually set to 0 in file system_LPC11x.h - also try open the definition from the C file and you get a blank window.

Again, the program compiles and operates properly, its just that Eclipse is snarled up.

Thanks in advance for any help here,
Best Regards, Dave

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Sat Apr 09 00:02:13 MST 2011
How did you create the project that is causing your problems?

My guess is that you did a copy/paste of a projects directory using Windows Explorer (the key point being your did it OUTSIDE of the IDE) and then renamed it and started Eclipse. If you do this, your project will be confused as there is stuff that is stored in the .cproject/.project files that will refer to your old project and not your new one. If you want to copy a project, you should do it inside of the IDE, and then it will 'fix up' all the things that it needs.

If this sounds familiar, shutdown the IDE, edit the .cproject/.project files and search/replace the old project name for the new project name and then restart the IDE.
NOTE: editing these files is not recommended, but might get you out of this hole.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by DaveNadler on Fri Apr 08 19:11:42 MST 2011
${workspace_loc...} is great if you need to refer to a related project,
for example "${workspace_loc:/lib_small_printf_m0/inc}".

For files that must be specific to a particular project and hence a copy included in each project, for example config/system_LPC11xx.h (which must be tailored to each particular board), the relative path "../config" should be used.

In my example, I have a workspace containing projects for several different boards. Thus the path to the "config" directory [I][B]must[/B][/I] be relative, but the path to lib_small_printf_m0 should be based on ${workspace_loc...}.

[B]Now, back to the question at hand:
[/B]
Eclipse is quite confused:
- gives incorrect macro expansions on mouse-over (not matching the actual compilation)
- opens the wrong file when asked to show a declaration of a macro (or opens an empty window when the erroneous path has been removed from the system)

(1) How does one get Eclipse to sync to the actual path used in the compilation ?
(2) Where is this information (ie, macro defined values, path to macro definition) cached ?

Thanks in advance for any help,
Best Regards, Dave

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Fri Apr 08 15:41:18 MST 2011
The whole point of ${workspace_loc...} is that it is NOT absolute - it is relative to the workspace.

So, assuming your workspace is located in c:\workspaces, ${workspace_loc:project/path} will expand (at build time) to c:\workspaces\project\path. If you 'move' your workspace to d:\home\me\my_product, then it will expand to d:\home\me\my_product\project\path.

The advantage of using the workspace_loc macro is that it doesn't rely on relative or absolute locations - it is *workspace* relative.

I'd really recommend that you use workspace_loc...

If you are still having problems, I suggest you post a screeenshot of your Directories settings and the output from the build that is wrong.