[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] problems with ScannerConfigurationDiscoveryProfile
|
You don't have to implement the classes, just point to GCC ones.
Yes, I currently have to do so. But Eclipse tells me:
Access to referenced class
'org.eclipse.cdt.make.internal.core.scannerconfig2.PerProjectSICollector'
in attribute 'class' is discouraged
Access to referenced class
'org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCScannerInfoConsoleParser'
in attribute 'class' is discouraged
Access to referenced class
'org.eclipse.cdt.make.internal.core.scannerconfig2.GCCSpecsRunSIProvider'
in attribute 'class' is discouraged
Access to referenced class
'org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCSpecsConsoleParser'
in attribute 'class' is discouraged
It's only warnings, but is there a guarantee that it won't become errors
in future releases?
P.S.
My extension point:
<extension
id="LSBManagedMakePerProjectProfileC"
name="GNU (LSB) C/C++ managed make per project SCD profile"
point="org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile">
<scannerInfoCollector
class="org.eclipse.cdt.make.internal.core.scannerconfig2.PerProjectSICollector"
scope="project">
</scannerInfoCollector>
<buildOutputProvider>
<open></open>
<scannerInfoConsoleParser
class="org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCScannerInfoConsoleParser">
</scannerInfoConsoleParser>
</buildOutputProvider>
<scannerInfoProvider
providerId="specsFile">
<run
arguments="-E -P -v -dD ${plugin_state_location}/specs.c"
class="org.eclipse.cdt.make.internal.core.scannerconfig2.GCCSpecsRunSIProvider"
command="/opt/lsb/bin/lsbcc">
</run>
<scannerInfoConsoleParser
class="org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCSpecsConsoleParser">
</scannerInfoConsoleParser>
</scannerInfoProvider>
</extension>
Andrey.
On Wed, 09 Sep 2009 18:04:12 +0400, Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
wrote:
On Wed, Sep 9, 2009 at 8:47 AM, Andrey Tretyakov
<andrromeda@xxxxxxxxx>wrote:
I think, it would be good NOT to define my own
scannerConfigDiscoveryProfileId and
ScannerConfigurationDiscoveryProfile at
all, just inherit it from cdt.managedbuild.tool.gnu.c.compiler and
dynamically change "run -> command" from "gcc" to "lsbcc".
I do not think it is possible to do using only public interfaces.
Managedbuilder plugin itself uses illegal access to cdt.make.core
internal
classes. The public API just is not defined at that point.
On the other hand I fail to see your problem with defining your own
extension. You don't have to implement the classes, just point to GCC
ones.
Andrew
Andrey.
On Wed, 09 Sep 2009 16:34:47 +0400, Andrew Gvozdev
<angvoz.dev@xxxxxxxxx>
wrote:
Hi,You can change command and arguments in "run" element in the
extension
point or in UI. Why do you need to change it dynamically? Are you
talking
about command generating compiler specs?
Andrew
On Wed, Sep 9, 2009 at 6:02 AM, Andrey Tretyakov <andrromeda@xxxxxxxxx
>wrote:
Hello,
I'm developing my own gcc-like toolchain (based on CDT GCC). It uses
the
special compiler "lsbcc" instead of "gcc".
I know, that I also have to override scannerConfigDiscoveryProfileId
attribute and use ScannerConfigurationDiscoveryProfile extension
point. I
need to use the same ScannerConfigurationDiscoveryProfile for
"lsbcc", as
for "gcc", except the "command" attribute (i.e. to replace "gcc"
command
with my special compiler command ("lsbcc")). So, it seems unnecessary
to
implement manually all interfaces ScannerConfigurationDiscoveryProfile
points to. I also can't import into my plug-in the classes that are
used
by standard GCC, because they use a lot of other internal classes.
So, the question is:
Is there a way to dynamically change "command" attribute for
ScannerConfigurationDiscoveryProfile?
If there is no, then are there public default implementations of
needed
interfaces of ScannerConfigurationDiscoveryProfile?
P.S.
I use CDT 4.0.x, 5.0.x, 6.0.
Best regards,
Andrey.
_______________________________________________
cdt-dev mailing list
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