| 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? 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?) 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. 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. Cheers, Richard From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail 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 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 Cheers, Richard From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail 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. |