Skip to main content

[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




Back to the top