Eclipse Community Forums: C / C++ IDE (CDT) » Juno CDT discovery not working

Home » Language IDEs » C / C++ IDE (CDT) » Juno CDT discovery not working(Using an Microware/Radisys compiler with make environment)

Show: Today's Messages :: Show Polls :: Message Navigator

Juno CDT discovery not working [message #896851]

Fri, 20 July 2012 07:09

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

I'm trying to use Eclipse CDT with my make environment. Using the "Makefile Project with Existing Code" it was easy to set up the compilation part.

Now I'm trying to get the discovery part working and am struggling with this option.

1) I'm unaware of the difference between the "Project Settings -> C/C++ Build -> Discovery Options" and "C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Providers Tab"

2) The compiler I am using in the make environment is a cross compiler by Microware (nowadays Radisys) and thus I changed the compiler invocation command to "xcc", which is the executable and included in the path environment.
If I understand the invocation commands for gcc correct, they intend to get the defines and include paths which are standard for the compiler. So I changed those to the xcc arguments, that provide this information (and tested it in the console compiling the empty spec.c file provided by Eclipse).

3) Unfortunately after a clean build (I can see the xcc commands in the output console with the includes (-v) and defines (-d)) the "C/C++ General -> Paths and Symbols" as well as the "C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Entries Tab" is still empty.

I tried several toolchain options and Discovery profiles as I'm unsure which one to use with my toolchain.

Any help is appreciated! Thanks in advance!

Report message to a moderator

Re: Juno CDT discovery not working [message #896999 is a reply to message #896851]

Fri, 20 July 2012 18:18

Andrew Gvozdev

Messages: 257
Registered: July 2009

Senior Member

cdt discovery wrote on Fri, 20 July 2012 03:09

1) I'm unaware of the difference between the "Project Settings -> C/C++ Build -> Discovery Options" and "C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Providers Tab"

"Discovery Options" is deprecated and going to be phased out.

cdt discovery wrote on Fri, 20 July 2012 03:09

2) The compiler I am using in the make environment is a cross compiler by Microware (nowadays Radisys) and thus I changed the compiler invocation command to "xcc", which is the executable and included in the path environment.
If I understand the invocation commands for gcc correct, they intend to get the defines and include paths which are standard for the compiler. So I changed those to the xcc arguments, that provide this information (and tested it in the console compiling the empty spec.c file provided by Eclipse).

Where did you add this "xcc" invocation? Go to "Preprocessor Include Paths" tab "Providers" and make sure "CDT GCC Builtin Settings" enabled. After that change the command in the provider options. You may need to go to "Workspace Settings" link as instructed.

cdt discovery wrote on Fri, 20 July 2012 03:09

3) Unfortunately after a clean build (I can see the xcc commands in the output console with the includes (-v) and defines (-d)) the "C/C++ General -> Paths and Symbols" as well as the "C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Entries Tab" is still empty.

You can also "Allocate console" in the provider options to check output. This console is different from build console. You can find it in "Display Selected Console" button on the toolbar of the Console View. What is the output, is it the same format as GCC?

Andrew

Report message to a moderator

Re: Juno CDT discovery not working [message #897188 is a reply to message #896999]

Mon, 23 July 2012 05:40

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

Andrew Gvozdev wrote on Fri, 20 July 2012 14:18

"Discovery Options" is deprecated and going to be phased out.

Does that mean I should uncheck "Automate discovery of paths and symbols" in the "Discovery Options" or is the setting already ignored?

Andrew Gvozdev wrote on Fri, 20 July 2012 14:18

Where did you add this "xcc" invocation? Go to "Preprocessor Include Paths" tab "Providers" and make sure "CDT GCC Builtin Settings" enabled. After that change the command in the provider options. You may need to go to "Workspace Settings" link as instructed.

Originally I put the "xcc" invocation on the "Discovery Options" page as well as on "C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Entries Tab -> CDT GCC Build Output Parser" In the "CDT GCC Builtin Settings" I have "${COMMAND} -P -b -pp ${INPUTS}" which I thought would take the invocation command and use the currently compiled file of the make environment.
I have "CDT User Setting Entries" enabled but with "Share setting entries between projects" and "Store entries in project settings folder" unticked.
Also the "CDT GCC Build Output Parser" with the invocation mentioned above, also both settings unticked, container is project, heuristics are enabled and enable language settings also enabled.
"CDT GCC Builtin Compiler Settings" also both top boxes unticked, "Command" has been tried with "${COMMAND} -P -b -pp ${INPUTS}" and "xcc -P -b -pp ${INPUTS}".
"CDT Managed Build Settings Entries" have been enabled.

Andrew Gvozdev wrote on Fri, 20 July 2012 14:18

You can also "Allocate console" in the provider options to check output. This console is different from build console. You can find it in "Display Selected Console" button on the toolbar of the Console View. What is the output, is it the same format as GCC?

Even though I enabled this option, I only get the "CDT Global Build Console" and the project specific build console. So it seems, the invocation fails. With a different setting (maybe toolchain, or whatever I tried already) I could see this console window - however it was empty then as well.

Thanks so far!

Edit:
The "Preferences -> C/C++ -> Build -> Settings" still listed gcc, however changing that didn't improve the situation.
At the moment I configured the project for "Cross GCC" and "Gnu make builder".

[Updated on: Mon, 23 July 2012 05:57]

Report message to a moderator

Re: Juno CDT discovery not working [message #897232 is a reply to message #897188]

Mon, 23 July 2012 10:13

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

Update:

I modified the field "Compiler Command pattern" from "xcc" to "=(xcc)" and made the project's "CDT GCC Build Output Parser" shared which improved the situation a little bit.
Now I get some output in the "Builtin Compiler Settings GNU C" Console.

12:03:28 **** Running scanner discovery: CDT GCC Builtin Compiler Settings ****
...
I can see the command I expected xcc -P -b -pp <My Path>/spec.c and the compiler's standard include paths and defines are returned (exit code 0).

However, the entries in the project settings "C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Entries Tab" are still not filled with entries and abviously once I right-click on the project and click "Index -> Rebuild" or "Index -> Freshen All Files" the types are still unresolved and unknown.

Report message to a moderator

Re: Juno CDT discovery not working [message #897340 is a reply to message #897232]

Mon, 23 July 2012 16:24

Andrew Gvozdev

Messages: 257
Registered: July 2009

Senior Member

Can you post the output? Perhaps the output is different from that of gcc and the parser cannot handle it?

Thanks,
Andrew

Report message to a moderator

Re: Juno CDT discovery not working [message #897466 is a reply to message #897340]

Tue, 24 July 2012 08:28

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

Sure. The xcc gets its include paths with -v parameter which I thought may be causing trouble, but the invocation command returns standard -I and -D. Is there anywhere (except source) where one can see or modify the pattern just like the error parsers?

Note: I removed some include paths and defines since they are of the same kind.

Invocation command:

10:12:05 **** Running scanner discovery: CDT GCC Builtin Compiler Settings ****
xcc -b -pp C:/Programme/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c
"cpfe -m --target=0 -Ic:\OS\SRC\DEFS --translate_names_1 -D_UCC -D_MAJOR_REV=2 -D_OSK -w --Extended_ANSI -E -P C:/Programme/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c"
exit status = 0

Build command:

xcc.exe -v=C:\OS\COMP\defs -a -r -eas=P:\Some\Other\Path -tp=403,ldlcd -td=c:\tmp -dLIB_VERS="123-45.678.111xx" P:\Path\To\File\src\MyFile.c

Report message to a moderator

Re: Juno CDT discovery not working [message #897584 is a reply to message #897466]

Tue, 24 July 2012 15:24

Andrew Gvozdev

Messages: 257
Registered: July 2009

Senior Member

cdt discovery wrote on Tue, 24 July 2012 04:28

10:12:05 **** Running scanner discovery: CDT GCC Builtin Compiler Settings ****
xcc -b -pp C:/Programme/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c
"cpfe -m --target=0 -Ic:\OS\SRC\DEFS --translate_names_1 -D_UCC -D_MAJOR_REV=2 -D_OSK -w --Extended_ANSI -E -P C:/Programme/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c"
exit status = 0

Is that all you are getting in the output? That is not going to get parsed. "GCC Builtin Compiler Settings" parser is expecting output like that of GCC:

#include "..." search starts here:
#include <...> search starts here:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/include
End of search list.

#define __GNUG__ 3
#define __GNUC_MINOR__ 4
#define __GNUC_PATCHLEVEL__ 5
#define __SIZE_TYPE__ unsigned int
#define __PTRDIFF_TYPE__ int

...

Andrew

Report message to a moderator

Re: Juno CDT discovery not working [message #897978 is a reply to message #897584]

Wed, 25 July 2012 14:38

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

Okay, so I guess there is no easy way to modify the output handling as in modify the pattern to recognize include paths and defines?

Since I have no control over the compiler's output I would either have to parse it to generate the requested output or if possible provide/get a plugin, right?

Nevertheless thanks a lot for your help on this!

Report message to a moderator

Re: Juno CDT discovery not working [message #898081 is a reply to message #897978]

Wed, 25 July 2012 18:23

Andrew Gvozdev

Messages: 257
Registered: July 2009

Senior Member

There is another parser that handles similar output, "XLC Builtin Compiler Settings". I tried to feed your output and luckily it took it as its own. Try it.

Thanks,
Andrew

Report message to a moderator

Re: Juno CDT discovery not working [message #898319 is a reply to message #897466]

Thu, 26 July 2012 08:10

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

Thank you!! That did the job for the builtin compiler settings!
(Just in case someone else runs into the same problem: I installed "XLC C/C++ Compiler Support" from the Eclipse Marketplace.)

But the "Build Output Parser" still does not provide any output. As I mentioned above, the include paths start with -v and the defines with -d:

cdt discovery wrote on Tue, 24 July 2012 04:28

xcc.exe -v=C:\OS\COMP\defs -a -r -eas=P:\Some\Other\Path -tp=403,ldlcd -td=c:\tmp -dLIB_VERS="123-45.678.111xx" P:\Path\To\File\src\MyFile.c

As I am quite new to Eclipse (or incapable of searching) - how/where did you gather the information that the XLC parser would help me out? Even though I got your hint, I was not able to find any information on it using a standard search procedure.
Maybe this is why I also failed to find the right information, which would help me out with the output parser...

Report message to a moderator

Re: Juno CDT discovery not working [message #898482 is a reply to message #898319]

Thu, 26 July 2012 12:59

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

Anyway, I'm running a tool up front the xcc call, which basically receives the same input paths and defines but with "-I" and "-D" respectively. Putting that command as the "Compiler command pattern" for the "XLC Build Output Parser" works to some degree.

When building libraries, the same project/file is compiled with different definitions of a define in one build run (e.g. First with -DDISPLAY_TYPE=A, then with -DDISPLAY_TYPE=B). However in the project's entry list as well as in the file's entry list, only the defines of the last build seem to be listed.
First I had the container selected as project, but changed to file later on, when I discovered that some defines were only given for files in a certain make file.

And another question I have: In case a define of the compiler builtin defines is redefined in the make environment and passed to the compiler, the discovery lists both (obviously) in their according locations. Does the discovery then use the one of the build output?

Report message to a moderator

Re: Juno CDT discovery not working [message #898597 is a reply to message #898482]

Thu, 26 July 2012 19:13

Andrew Gvozdev

Messages: 257
Registered: July 2009

Senior Member

Indexer will use macro definitions in the order they are shown in "Entries" tab, i.e. it will look first at "User Settings Entries" and then at the other providers in order. You can change the order in "Providers" tab.

Report message to a moderator

Re: Juno CDT discovery not working [message #898701 is a reply to message #898597]

Fri, 27 July 2012 09:19

cdt discovery

Messages: 10
Registered: July 2012

Junior Member

Does use in order mean takes first it finds or last one wins?

And sorry, my example was wrong - of course the latter definition would be taken.
But the example is actually this:
For the first library, -DDISPLAY_TYPE_A= is passed and for the second one -DDISPLAY_TYPE_B= is passed.
So I would expect to find both defines in the discovered output list, since it's the same build, or what am I missing?

Report message to a moderator