Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] ScannerInfo UI extension point issue

Hi Bob,
please raise a PR and it will be addressed. You are on a right track; those protected functions should be public.

Thanks,
Vmir



"Monteleone, Robert" <robert.monteleone@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

06/08/2005 04:24 PM

Please respond to
"CDT General developers list."
To
<cdt-dev@xxxxxxxxxxx>
cc
Subject
[cdt-dev] ScannerInfo UI extension point issue





The Intel Eclipse/CDT compiler integration currently supports the "Scannerinfo" standard make support in CDT 2.1.

Specifically, the extension points:
 
  org.eclipse.cdt.make.core.ScannerInfoConsoleParser
  org.eclipse.cdt.make.core.ExternalScannerInfoProvider

I am working on upgrading the Intel compiler integration to work in the CDT 3.0 environment.
I am currently focused on the standard make support, though it appears that there is similar
support available in the context of the managed make system.

These are the extensions points I am implementing against:

   org.eclipse.cdt.make.core.ScannerConfigurationDiscoveryProfile
  org.eclipse.cdt.make.ui.DiscoveryProfilePage

The UI extension point, org.eclipse.cdt.make.ui.DiscoveryProfilePage , has been problematic.
Through this extension point, I am hoping to get references to the Intel compiler on the standard make "Discovery" page.

First, I created a new Intel standard make ui plugin and then created a plugin.xml with references to the extension point DiscoveryProfilePage appropriately. Then, I cloned the files  

   
     GCCPerProjectSCDProfilePage.java
     GCCPerFileSCDProfilePage.java

renamed them, and tweaked them to reference the proper plugin etc.

The problem is how to proceed from this point. The files will not compile because they contain indirect references to protected functions in class AbstractDiscoveryPage, which is being extended by my cloned copy of GCCPerProjectSCDProfilePage (ICCPerProjectSCDProfilePage).

Specifically:

ICCPerProjectSCDProfilePage.java
---------------------------------------------------------------------------------------------------------------------------

public class ICCPerProjectSCDProfilePage extends AbstractDiscoveryPage { ...

the following reference will not compile because the reference getProject is not accessible:
 
      getContainer().getProject() != null

It compiles in the corresponding GCC file because the file is located in the org.eclipse.cdt.make.ui package
along with AbstractDiscoveryPage, AbstractDiscoveryOptionBlock and related code.
---------------------------------------------------------------------------------------------------------------------------

AbstractDiscoveryPage.java

public abstract class AbstractDiscoveryPage extends DialogPage {
   protected static final String PREFIX = "ScannerConfigOptionsDialog";
   protected static final String PROFILE_GROUP_LABEL = PREFIX +    
                          ".profile.group.label";
   private static final String VARIABLES_BUTTON = PREFIX +
                          ".common.variables.button";    
   protected AbstractDiscoveryOptionsBlock fContainer; // parent
   
   /**
    * @return Returns the fContainer.
    */
   protected AbstractDiscoveryOptionsBlock getContainer() {
       return fContainer;
   }...

----------------------------------------------------------------------------

I experimented by cloning the AbstractDiscoveryPage and the AbstractDiscoveryOptionBlock java code from the org.eclipse.cdt.make ui package to the Intel make ui package.

This doesn't seem like a very good approach, and I am not certain it will work properly. I also tried cloning all other files that are adjacent to those files, but that seems worse.

Can anyone offer any insight as to what the proper approach should be here?

Thanks,

Bob


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top