[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Need help with ScannerInfoProvider and CDT 6.0
|
I may be at fault here. There is a bug introduced in CDT 6.0
200909110608 in DiscoveryTab.java. I tried circumventing it by adding a
scannerConfigDiscoveryProfileId to some InputType specifications in our
build definition which had no previous specifiers. It may be that the
discovery profile specification circumvents the setting of the default
include path I expect.
When I made a patch to DiscoveryTab.java, reverted the change above, and
was sure to create a new project, the indexer works again and finds the
standard C include in the test example.
Would you like me to still open a bug? I was hoping to get someone I
could discuss our build definition with as I would like to clean it up
somewhat. I am rewriting the project to be cleaner and would like to
avoid passing on any bad practices.
-- Jeff J.
On 07/10/09 06:09 PM, Andrew Gvozdev wrote:
Hi Jeff,
I don't think there was any intended change to the way how scanner
discovery is working. Please, open a bug in bugzilla to figure that out.
It would be helpful to define what "recently" is if you can be more
specific.
Thanks,
Andrew
On Wed, Oct 7, 2009 at 6:00 PM, Jeff Johnston <jjohnstn@xxxxxxxxxx
<mailto:jjohnstn@xxxxxxxxxx>> wrote:
Our project has had its own ScannerInfoProvider for a long time
using the old org.eclipse.cdt.core.ScannnerInfoProvider extension.
We added it to perform a make -W per file to gather the include
files and macros.
This got us all the include paths specified in the Makefile itself,
but not the default includes. At the end of the include fetching,
we would use:
IScannerInfo info =
(IScannerInfo)ManagedBuildManager.getBuildInfo(project);
String[] baseIncludes = info.getIncludePaths();
This used to get the default include path (e.g. /usr/include) until
recently. Now, the info.getIncludePaths(project) returns an empty
array.
In debugging, I noticed that the CDT is calling our
ScannerInfoProvider with one of two imaginary files: __cdt__.cpp and
__cdt__.c.
Has the ScannerInfoProvider interface been changed such that the
default includes are to be generated by "our" ScannerInfoProvider
when either of these two files are presented or should the
ManagedBuildInfo still provide this?
-- Jeff J.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev