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
