Eclipse Community Forums: C / C++ IDE (CDT) » Build Output Parser

Home » Language IDEs » C / C++ IDE (CDT) » Build Output Parser - no rebuild(How to update without rebuilding the project)

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

Build Output Parser - no rebuild [message #1822857]

Mon, 16 March 2020 00:35

ND OpenCode

Messages: 2
Registered: March 2020

Junior Member

Skip first paragraph to avoid my vent rant.
I have to express my frustration as an end user how difficult eclipse is compared to tools nowadays, however, I know this is unnecessary, as its very clearly not just frustrating for me and so many competing IDEs have borne out of this frustration from other end users so this is not meant to be taken negatively but more so trying to bridge the gap that clearly exists from end-user and developer. End of my vent.

Ok now the issue. I have been trying to decipher the "Build Output Parser feature" for last week now. This feature can be found in Project > properties> Preprocessor Include Paths and Macros > CDT GCC Build Output Parser.

I have a define that I would like for the feature to pick up but the only way for me to get it to work is if I set Container to keep discovered entries to Folders (use when settings are the same for all folders in project). The issue is that it took me a good few hours trying different options/settings in order to come to this conclusion. The reason why it took so many hours is because I kept on having to rebuild the project (which takes about 20 minutes) each time and also reindex. Both take a long time. A simple performance improvement here is simply to re-parse the same build log. That way you can change the providers settings and reindex and see if it solved your problem. Do I have to rebuild each time? Or am I overlooking a undocumented trick that already takes advantage of the previous build log?

Another improvement would also be to add a scroll window to the options windows as I have to resize each time in order to see the options. If the language providers selection screen have a scroll window why not this one??

Bonus:
One final improvement is why are there three different container options? Wouldn't it be simpler to just keep the scope to each file and if multiple files use the same entries, expand the scope from folder to project. Why complicate it with three different possible scenarios that surely require its own type of debugging just to get the project settings right. And that begs the other question, its likely my understanding, but I would assume the first option which is "File (use when entries vary for each file)" would be the most inclusive and non-discriminatory option. I thought it would create entries for each file but in my case only one that works is the "Folder" option. This is not intuitive behavior (and doesn't seem deterministic) so what is actually going on with each of these settings?

Report message to a moderator

Re: Build Output Parser - no rebuild [message #1822991 is a reply to message #1822857]

Tue, 17 March 2020 16:54

David Vavra

Messages: 1426
Registered: October 2012

Senior Member

The Build Output provider just scans the log file looking for -I and -D flags.

If they aren't present, it won't help much.

Report message to a moderator

Re: Build Output Parser - no rebuild [message #1823062 is a reply to message #1822991]

Thu, 19 March 2020 03:00

ND OpenCode

Messages: 2
Registered: March 2020

Junior Member

I understand that. My question is there a way to rescan the build output when you change a setting in the language provider?

Because I get different behavior from:
File
Folder
Project

and also heursitic. And since each build takes 20 minutes, having to clean and rebuild is a time consuming process just to figure out each setting. It would be a lot simpler if it just re scanned the build output each time the setting changes.

I would like to understand the nuances as its not immediately clear given that only Folder works - and I can't figure out what File and Project is because of that. There is a pattern that is not immediately obvious.

I also am wondering why have these three different options? Seems like configuration that could be eliminated with different approach to the implementation.

[Updated on: Thu, 19 March 2020 03:04]

Report message to a moderator

Re: Build Output Parser - no rebuild [message #1823064 is a reply to message #1823062]

Thu, 19 March 2020 04:50

David Vavra

Messages: 1426
Registered: October 2012

Senior Member

I'm guessing the answer is NO.
There is a dialog to select when the scanner is called:
Project --> Properties --> Builders
It has limited events to select from.
One of them is "After a clean".
You might try a makefile with a vacant "clean" target until a time when you really need it.
You still would have to figure out how to set the console log to a previous value.

The scanner is just looking at the command lines in the log.
You could try running the make in dry mode. (-n or --dry-run flags).
You probably would need the -B flag, too.
It causes make to think a clean has been run.

OR, examine the java code to find out how it is run.
You might be able to assign a shortcut to it.

I'm not sure what you mean by File, Folder and Project.
If you mean the options at the bottom of the Provider dialog for the Build Output Provider,
then those are where the results are stored.
I don't understand your confusion.

Frankly though, wouldn't it be simpler to find all of your included headers then search for where they are stored? A small perl script shouldn't take that long.

If by "heuristic", you mean the "Allow heuristic resolution of Includes",
that is Indexer option unrelated to the Build Output parser.
I keep it enabled along with "Index source files not included in build".
The Build Output parser looks for paths and macros on the compiler command lines.
It's mostly telling the Indexer where the includes might be found and little else.

If you actually meant the checkbox in the Build Output parser dialog
labelled Use heuristics to resolve paths then according to the help files:
Quote:

Use heuristics to resolve paths
The provider will try to find the best match for the discovered path in the project or workspace trying several heuristics. If disabled, the discovered paths will stay as they appear in build output.

I suspect there's more to your issue that you are omitting.

[Updated on: Thu, 19 March 2020 05:07]

Report message to a moderator

Previous Topic:	Arduino Library Management With Symlinks
Next Topic:	[Arduino] Support multiple version libraries

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 14:22:15 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter