Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Feedback

Hi Sascha,


Thanks for the good feed-back!


My comments are embedded below.





-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sascha Radike
Sent: Friday, March 30, 2007 7:41 PM
To: 'CDT General developers list.'
Subject: [cdt-dev] Feedback




I'd like to provide some feedback regarding the new project model. I have

not had an in depth look yet but here's a collection of bugs and questions.

I haven't had the time to raise individual bugs yet.



* Wizards



--- Is it really neccessary to have three different wizard categories for

C/C++/CDT ?


Instead of...


            C++ Project


            C Project


            CDT Project


Maybe something like ...


            C Project

            C++ Project


            CDT Project

[Mikhail] I like the current variant better, although this is only my opinion. I’m leaving this for the further discussion by the community.


--- When selecting "Advanced settings" on the configurations page of the new

project wizard, a new (temporary) project gets created. When cancelling the

wizard, the project gets deleted. But when starting the wizard again and

setting the project to the same name again, an error message appears "File

with specified name already exists".

[Mikhail] This seems like a bug. Could you please raise a bugzilla report?



* CDTWizard extension point



--- ICNewWizard: Why does a "Tree" get passed to createItems(Tree tree,

boolean supportedOnly) ? Isn't this a bad design? I noticed the wizard

calling this method is interested in ICWizardHandlers only anyway and these

handlers provide name and icon (getName(), getIcon()). So is there a reason

why the raw tree gets exposed to implementors of this extension point

instead of asking them for an arrary of ICWizardHandler[] ?

[Mikhail] This is the question to Oleg. Oleg, what would you say?



* Build



--- Are build properties supposed to be used only for values being defined

via extension point or is possible to set custom data ? I'd like to

associate custom data via API. And it looks like it is possible if the

property type has been defined:

IBuildProperties.setProperty("", ""); I

just wonder if it is officially supported. Hope so.

[Mikhail] That’s a good question. Initially it was not intended for the build properties to maintain the custom values that are not specified via a buildProperties extension. Although I guess this should be possible.

I need to double-check this and to think about it some more.

Could you please raise a bugzilla enhancement so that we don’t forget about this and I think we could do this for RC0.


--- Better API doc would be really nice :) There alot of non-doc methods in

IConfiguration and other build interfaces. The ManagedBuildManager is

missing docs, too. I know, APIs haven't been freezed yet.

[Mikhail] Will do. In any way feel free to ask any questions you have regarding the new API.



* Build UI



--- All build ui combo boxes are editable, but they shouldn't be. (Artifact

Type, Builder type, tool chain edit, ...)


--- Why can't the build directory bet set for managed build? This is a

feature I was looking forward to. I'd prefer setting \bin as my root output

folder rather than having all my output folders right in the project root.

It should be possible to select at least a workspace folder.

[Mikhail] I agree. The problem is that there is many code in the managed build assuming the build directory is the /<project_name>/<config_name>. My most worry about this is the Gnu Makefile Generator that has a lot of complicated (sometimes duplicated) logic assuming the /<project_name>/<config_name> folder is the CWD. I’ll revisit this again. Probably we could easily do it for the Internal Builder. Could you raise a bugzilla enhancement regarding this?


--- Small stylistic enhancements: Properties: 'C/C++ ToolChain edit' should

be something like 'C/C++ Tool chain editor'

[Mikhail] I agree with this

 / 'Language mappings' should

have 'C/C++' prefix.

[Mikhail] I agree with this as well. This page was developed by the IBM guys, guys, what do you think about this?


--- Tool chain editor: Current builder might be confusing. In 'C/C++ Buld

settings' the builders are called 'Internal' and 'External' builder. But in

the tool chain editor they are called 'CDT internal builder' and 'Gnu Make


[Mikhail] I agree that the Internal builder representation in this two pages should have identical name.

As for the “External” builder, there might be more than one external builder integrations available.

The “Toolchain edit” tab allows selecting any builder available, as for the internal-external builder change functionality of the “Builder settings” tab, it works in the way similar to how it was in the 3.x, i.e. when the Internal Builder is changed to the “External” builder, the external builder that was previously used gets activated.

Probably it is a good idea to have all available builders be displayed in the builder selection combo for the “Builder Settings” page, i.e. make it behave as the one on the “Tool-chain edit” page.

What do others think?


It is also possible to select the Gnu Make Builder, even when the

'External builder' is not selectable in the build settings (This does enable

the external builder. But switching back to internal does disable it again).

[Mikhail] Yes, and this is made by intention. The tool-chain edit tab does not put any special restrictions on the tool-chain modifications that can be performed (other than that the elements not supporting the Managed Build can not be selected when the Managed Build is on).




* Other



Just as a reminder: :) I really hope the user help/docs will be rewritten or

updated. Alot of topics are pretty much out of date.

[Mikhail] Yes, we are planning to work on the documentation as soon as we have time and it will definitely be updated for the 4.0.


Anyway, I think CDT made a big step forward for 4.0. Rock on.







cdt-dev mailing list


Back to the top