[cdt-dev] Re: [Bug 51269] New: MakeTarget invokes only make builder disr

[Vladimir Hirsl <vhirsl@xxxxxxxxxx>]

No problem. Just making it 'lighter' reading.

Thanks,
Vmir

> If you don't mind, could we push this discussion onto the cdt-dev 
> mailing list, I know of other that would have comments on this.
> 
> Thanks
> Dave.

>>[vmir]
Dave,
let me put this in perspective.
I am working on a feature to improve user out of box experience with 
regards to CDT standard make projects. i.e., pre-populate include paths 
and symbol definitions for a buildable project.

The idea is to register an error parser with a make builder and capture 
include paths (-I) and symbol definitions (-D) from the build output. When 
the make build is done, another builder would run and 'consolidate' the 
discovered scanner configuration (i.e. transform cygpaths and relative 
include paths to absolute or/and variable extended paths, manage multiple 
scanner configurations, etc) and update project's scanner configuration 
(currently managed by MakeScannerInfoProvider).

There are couple of requirements to make this possible (usable):

- Invoke the new builder after make builder when building make targets. PR 
51269. It is not a showstopper, but it would be very nice to have this in 
CDT 2.0 timeframe. For now, the new builder will be invoked only when the 
project is built/rebuilt.

>[dinglis]
No issues here as mentioned in the bug, I plan to make invocation of other 
builders a user configuration, like Eclipse 3.0.

[vmir]
It is great you are planning to address this issue in CDT 2.0 timeframe, 
however I would be very grateful if you can elaborate more on the subject, 
since I am not familiar with the new (E 3.0 vs 2.x) way of invoking 
builders.

>>[vmir]
- Make error parsers builder specific. There is another part of scanner 
configuration discovery that I didn't mention previously. The new builder 
will also retrieve compiler's intrinsic scanner info from the 'specs' file 
by invoking gcc/g++ -c -v dummy.c. Compiler's intrinsic scanner info will 
be added to the scanner configuration discovered during the make build 
process. I was planning to reuse ErrorParserManager with another error 
parser to capture the output from reading the specs file, but I don't want 
this error parser to be used by the make builder. To make the distinction, 
new 'builderID' attribute added to the ErrorParsers extension point would 
be very helpful. I will create a PR for this.

>[dinglis]
If this is a error parser which is used by one builder, then why not just 
have that build invoke it directly, and not even register it as a CDT 
error parser extension.

[vmir]
That is certainly an option. However, the builder itself is an extension 
point so I was thinking in a spirit of greater extensibility that the 
output (error) parser should be an extension point too. Also, someone may 
come to an idea to use more information from the 'specs' output or to 
implement it for other compilers.

>[dinglis]
Or I could even by convinced to add a attribute the the extension which 
identifies an error parser as "private" and is not presented as a user 
enabled parser, then you own builder could specify it directly. I'm not 
sure I like the builderID option, since it ties it to an eclipse builder 
only usage scenario, and I'm not sure thats may alway by the case.

[vmir]
Sure, that would work too. As long as the make builder's list of error 
parsers is not polluted, I am content with the idea of using the specific 
error parser. Although that would prevent someone else contributing 
another error parser to the new builder. The reason that I asked for 
'builderID' (in fact it could be any attribute - id) is that I can detect 
all error parsers usable by the new builder. Hmmm. Maybe trying to reuse 
ErrorParserManager is not such a good idea?

>>[vmir]
I hope that you have a better picture now of what and why I am trying to 
do. If you have any suggestions or comments please do not hesitate to 
email me or give me a call.

>[dinglis]
One question, whats the user scenario to enable this functionality.

[vmir]
The plan is to have the feature enabled by default for new standard make 
projects. Then building the project either the first time after it is 
imported or as a quick fix for search/indexer problem marker that a 
file/type/... cannot be found will trigger it.