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.
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.
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.
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.
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.