| 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 Hi Richard, See my answers embedded
below. Mikhail From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Miskin 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 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. 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. |