[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] CDT New Project Model design initial draft

Hi there,

 

I just thought I’d let you know that I managed to work out how to integrate our tool with the CDT without requiring changes so I’ve not raised a Bugzilla entry for this. I used Mikhail’s suggestion to modify to prefix the compile/link commands with our tool. (I did this from a context menu rather than a properties page to avoid conflicts with the CDT properties page).

 

I added a dependency to our options file by creating (or updating if it already exists) a makefile.targets file when Cantata++ is enabled. This contains the following line:

$(OBJS) : ../ipg.cop

 

This gets included by the CDT generated Makefile and means that any changes to our options file force a rebuild of the object code. When Cantata++ is disabled the change to makefile.targets is removed.

 

One idea that might make things a little easier for 3rd party tool vendors would be to have an extension points to contribute Makefile fragments to the CDT Makefile generator. Then, for instance, my “$(OBJS) : ../ipg.cop” line could be written to the main Makefile and there wouldn’t need to be additional files written to the user’s project.  What do you think?

 

Cheers,

Richard

          


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Miskin
Sent: Friday 04 August 2006 11:33
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT New Project Model design initial draft

 

 

Mikhail,

 

See my response below

 

Richard

          


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail
Sent: Friday 04 August 2006 11:10
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT New Project Model design initial draft

 

Hi Richard,

 

See my answers embedded below.

 

Mikhail

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Miskin
Sent: Friday, August 04, 2006 12:52 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT New Project Model design initial draft

 

Hi Mikhail,

 

Sorry if this was a little off topic – I wasn’t sure how the New Project Model relates to the MBS as the document does describe a CDT Build System too.

 

It looks like using ITool.setToolCommand(String) may be precisely what I want for modifying the compile/link commands. Am I right that the way of getting at the ITool objects for a project is to use something like the following:

        IManagedBuildInfo buildInfo = ManagedBuildManager.getBuildInfo( pr_Project );

        IConfiguration[] configs = buildInfo.getManagedProject().getConfigurations();

        ITool[] toolObjs = configs[i].getToolChain().getTools();

     

Where “i” is the particular configuration we’ve decided we want to update. Is there a generic way to identify which tool is the compiler?

[Mikhail] No, MBS knows nothing and makes no assumption regarding the tool “nature” and behaviour. In case you know your compiler tool ID you may use it for getting the right tool. E.g. you may use the IConfiguration.getToolsBySuperClassId() for getting the tool you need, but in case you do not know the compiler tool ID, I’m afraid you won’t be able to determine which tool is a compiler and which tool is linker. The only hacky way I can think of is to determine the tool type by the tool inputs and outputs info, e.g. in case the tool accepts C/C++ files as an input, then the tool might be a compiler. I’m saying “might be” because generally the tool accepting C/C++ files may not be a compiler, but e.g. some pre-processor, etc.

 

Okay, I had a nasty feeling there wouldn’t be a clean way of doing this. I’ll work with specific tool IDs for now and make sure I have a way of specifying a list of tool IDs to work with.

 

Also if I call ITool.setToolCommand(String) do I need to do anything else to ensure that everything updates. (For example, if I have a properties page that calls setToolCommand will the C/C++ Build page update?)

[Mikhail] The way the Managed Build UI works currently is that the BuildPropertyPage creates and maintains the clone of the “real” configuration being edited. All modifications are performed with the “clone” configuration, and when “OK/Apply” is pressed, all settings from the “clone” configuration are copied to the “real” configuration belonging to the project.

So in case you make the change to the clone configuration being used by the BuildPropertyPage, the change will be reflected in UI. The problem is that you currently can not access the “clone” configuration being used from outside of the BuildPropertyPage, e.g. from another property page since the “clone” configuration is not really added to the project and maintained within the BuildPropertyPage currently. But I believe that with the new Project Model UI enhancements we should provide some general mechanism of adding custom UI components to the CDT Property pages as well as accessing the “Clone” configurations being used.

 

My alternative then is to have the Enable/Disable as a context menu rather than on the properties page. That should avoid any issues with the cloned data. It also means I can add in an extra nature and only show the Cantata++ properties page if it is enabled – so a better solution all round :)

 

Is it possible to change the BuildfileGenerator being used by a project? I can find a get method      ManagedBuildManager.getBuildfileGenerator( IConfiguration )

but no associated set method.

[Mikhail] The BuildfileGenerator is presented with the buildfileGenerator attribute of the builder definition, so when defining a custom builder you can specify a custom buildfile generator usng that attribute. In order to change the generator programmatically you might use the IBuilder.setBuildFileGeneratorElement() method, but note that this method is deprecated and could be removed in the future releases.

 

I think I’ll avoid this for now then. I think we can live without changing the Makefile, as (currently at least) all of our generated files are written to the same location as the object files and the Makefile’s clean rule just deletes the entire folder. It’d be nice to add the dependency to out options file but it’s not that big an issue.

 

What I’d like to be possible is to turn our tool on and off for an existing project rather than having to generate a specific project that has it enabled. For example; one of the facilities we provide is code coverage, it’d be nice if it was (as far as the user was concerned) just a case of ticking a box to build their system with code coverage rather than creating a new project which has coverage enabled and then importing all of their code and settings.

 

If the build system is being looked into for CDT 4.0 it might be worth considering how third party tools (e.g. tools that aren’t compilers but are used with them) than can be added into an existing tool chain. It’d be great if it were possible to avoid having to define a new buildDefinition for every CDT supporting compiler they want to work with. Otherwise the list of possible Project Types could get large very quickly with the side effect that the user could easily choose the wrong one.

[Mikhail] It will be possible to dynamically add/remove tools with the New Project Model, although I’m not sure whether this will help in your situation, since as I understand what you really need is to modify the existing tools rather than adding the new ones. It would be good if you could create and enhancement bugzilla and summarise and describe your requirements in more detail there so that we could consider the necessary functionality to be added to support your requirements. You are also welcome with any proposals regarding this.

 

Okay, I’ll try and work out precisely what we want to do and create an appropriate Bugzilla entry. Thanks for your responses.

 

Regards,

Mikhail

 

Cheers,

Richard

 

          


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail
Sent: Wednesday 02 August 2006 17:18
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT New Project Model design initial draft

 

Hi Richard,

 

The question regarding compiler command substitution is more like an MBS (Managed Build System)-specific question rather than a New Project Model –specific.

Speaking from the MBS point of view, there are already several mechanisms implemented that could be used in your case for the tool command substitution.

E.g. you can use the Build Macros mechanism, e.g. in your tool definition you can specify the tool command as “${Some_Macro_Name}” and define the macro that in some circumstances would be equal to “gcc” while in another circumstances would be resolved to “ipg_comp –comp gcc”.

You can as well modify the tool command programmatically by calling the ITool.setToolCommand(String) method.

 

>Another useful change would to allow extension points that let plugin providers hook into the generated makefile at specific locations. For instance adding rules to be called as part of the project clean so generated temporary files are removed correctly or adding dependencies on option files.

To allow custom makefile generation you could provide your own BuildfileGenerator. The Buildfile generator is specified with the builder:buildfileGenerator attribute. The attribute value should specify the fully-qualified class name implementing the org.eclipse.cdt.managedbuilder.makegen.IManagedBuilderMakefileGenerator interface.

You can also simply extend the GnuMakefileGenerator supplied with MBS and customize its behavior as needed.

As for the dynamic clean command customization, you could modify the clean command programmatically using the IConfiguration.setCleanCommand() method. You should be also able to use build macros in the clean command as well.

 

Mikhail

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Miskin
Sent: Wednesday, August 02, 2006 5:42 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] CDT New Project Model design initial draft

 

Hi there,

 

I’ve read through the draft and I’m not sure if the following idea/suggestion is covered by it or not. I don’t think it is, but I may have misunderstood the document.

 

The company I work for produces a software testing tool (Cantata++) that works by prefixing the compile and link commands of a C/C++ compiler with a compiler driver. This allows our tool to process the source code (adding logging calls etc) and then pass it directly on to the compiler to produce object code etc and also ensure our libraries are pulled in at link time.

 

It’d be nice if there was an easy way of programmatically changing the compile and link commands for the user. So if your normal build process uses:

gcc –c source.c

gcc source.o –o file.exe

 

The commands would be changed to:

ipg_comp –comp gcc –c source.c

ipg_comp –link gcc source.o file.exe

 

I’ve seen other tools that work in the same (or similar) way so this should be applicable to more than just our product.

 

I think the alternative would be for tool integrators to write new build definitions which are just change the compile and link commands. This would need to be done for every build type that we wanted to support and as CDT is applicable to more tools could become an overhead.

 

Another useful change would to allow extension points that let plugin providers hook into the generated makefile at specific locations. For instance adding rules to be called as part of the project clean so generated temporary files are removed correctly or adding dependencies on option files.

 

The guys at Wind River have seen this sort of requirement previously so they will probably have some useful input on this.

 

Cheers,

Richard

 

 

          


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail
Sent: Friday 21 July 2006 15:48
To: CDT General developers list.
Subject: [cdt-dev] CDT New Project Model design initial draft

 

Hi all,

 

I’ve attached the initial draft of the CDT New Project Model design to the bugzilla:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=115935

 

I hope the design could serve as the base and synchronization point for different enhancements planned to be done for leveraging the CDT 4.0 in the areas of better multi-language support, better usability and integrity, etc.

 

Your comments are highly appreciated.

 

Thanks,

Mikhail

 

 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

Any representations or commitments expressed in this email are subject to contract.

This message has been scanned for viruses and dangerous content. However, it is essential that the recipient also checks this message using commercially available mail scanning and anti-virus software. IPL Information Processing Limited accepts no liability for any loss or damage resulting from any virus or other dangerous content in this message.

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

Any representations or commitments expressed in this email are subject to contract.

This message has been scanned for viruses and dangerous content. However, it is essential that the recipient also checks this message using commercially available mail scanning and anti-virus software. IPL Information Processing Limited accepts no liability for any loss or damage resulting from any virus or other dangerous content in this message.

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

Any representations or commitments expressed in this email are subject to contract.

This message has been scanned for viruses and dangerous content. However, it is essential that the recipient also checks this message using commercially available mail scanning and anti-virus software. IPL Information Processing Limited accepts no liability for any loss or damage resulting from any virus or other dangerous content in this message.

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this email.

Any representations or commitments expressed in this email are subject to contract.

This message has been scanned for viruses and dangerous content. However, it is essential that the recipient also checks this message using commercially available mail scanning and anti-virus software. IPL Information Processing Limited accepts no liability for any loss or damage resulting from any virus or other dangerous content in this message.