RE: [cdt-dev] Re:org.eclipse.cdt.make.core.ScannerConfigurationDiscovery

["Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]

I've been trying to follow this thread but I do get the gist of it.
Scanner discovery is a mess and is in need of a total rewrite. I am
seriously considering this as part of our clean-up work for the build
system for CDT 5.1. I will definitely look for your input on how to make
things better and will set up a wiki page to capture everything in the
next week or two.

Cheers,
Doug. 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Frysinger
> Sent: Friday, May 23, 2008 5:25 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] 
> Re:org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProf
> ile:allowing inheritance ala superClass
> 
> On Fri, May 23, 2008 at 4:40 AM, Mike Frysinger wrote:
> > On Fri, May 23, 2008 at 4:33 AM, James Blackburn wrote:
> >>> as it stands, the only way a similar extensibility could 
> be attained 
> >>> is if org.eclipse.cdt.managedbuilder.internal.scannerconfig is 
> >>> exported so people can copy and paste the main gcc 
> >>> ScannerConfigurationDiscoveryProfile with references back to the 
> >>> internal classes.
> >>
> >> You can just point at PerProjectSICollector for your scanner info 
> >> collector couldn't you? The internal packages in the 
> make.core plugin 
> >> are currently visible externally.
> >
> > i'll take a look ...
> 
> so that's half the puzzle ... you can implement the 
> scannerInfoCollector with a simple line:
> public class DefaultGCCScannerInfoCollector extends 
> PerProjectSICollector implements IScannerInfoCollector3, 
> IManagedScannerInfoCollector {} but then again, this is an 
> exact copy of the DefaultGCCScannerInfoCollector.java, so 
> imo, it kind of sucks
> 
> the other half is still the scannerInfoConsolerParser.  this 
> isnt just one line, there's actual function definitions in 
> the default GCC one (although it still isnt a terribly large 
> file).  i have to imagine they exist for some reason and so i 
> cant just ignore the file.  but this gets back to the 
> duplication part which stinks.
> 
> so yes, if i copy into my plugin:
> /org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/manag
> edbuilder/internal/scannerconfig/DefaultGCCScannerInfoCollector.java
> /org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/manag
> edbuilder/internal/scannerconfig/ManagedGCCScannerInfoConsoleP
> arser.java
> 
> and then declare the discovery profile like so (which is 
> simply a duplication of the normal gcc one with the id/name 
> updated as well as the relevant class fields modified to just 
> point local):
>    <extension
>          id="TEST_GCCManagedMakePerProjectProfileC"
>          name="GNU C/C++ managed make per project SCD profile"
>          
> point="org.eclipse.cdt.make.core.ScannerConfigurationDiscovery
> Profile">
>       <scannerInfoCollector
>             class="DefaultGCCScannerInfoCollector"
>             scope="project">
>       </scannerInfoCollector>
>       <buildOutputProvider>
>          <open></open>
>          <scannerInfoConsoleParser
>                class="ManagedGCCScannerInfoConsoleParser">
>          </scannerInfoConsoleParser>
>       </buildOutputProvider>
>       <scannerInfoProvider
>             providerId="specsFile">
>          <run
>                arguments="-E -P -v -dD 
> ${plugin_state_location}/specs.c"
>                
> class="org.eclipse.cdt.make.internal.core.scannerconfig2.GCCSp
> ecsRunSIProvider"
>                command="my-gcc">
>          </run>
>          <scannerInfoConsoleParser
>                
> class="org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GC
> CSpecsConsoleParser">
>          </scannerInfoConsoleParser>
>       </scannerInfoProvider>
>    </extension>
> 
> i can tell my toolchain to use this and the include paths are 
> found properly.
> 
> but considering the internal versions of *.make.* are 
> exported, it seems a bit odd to not have the 
> *.managedbuilder.* versions as well ...
> -mike
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>