| RE: [cdt-dev] Feedback |
|
Hi Sascha, Thanks for the good feed-back! My comments are embedded below. Thanks, Mikhail -----Original Message----- Hi, 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++ C++
Project C C
Project CDT CDT
Project Maybe something like ... C/C++ C
Project C++
Project CDT 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("myProperty.id",
"Random...custom...data"); 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 Builder'. [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. Sascha _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |