[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Re:org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile:allowing inheritance ala superClass
|
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
>