Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Re: [Bug 51269] New: MakeTarget invokes only make builder disregarding the rest 
Vladimir Hirsl wrote:


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.
Or your builder could have some way of enabling error parsers on it in a extensible way. (extension point which just identifies which error parsers are compatible to your builder). Though this could lead to overloading of what the error parsers originally mean to be..... 


[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?
Again, that would be up to you to identify the error parsers that are compatible with you (whether you are a builder or not) 
but the issue of overloading comes up again/


[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.
Interesting... I take it that there would be some ui control the user can hit to disable this...(project properties?) encase they don't use gcc/g++, or is the method extensible for a build system that supports cross development or some other compiler. 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top