[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-test-dev] Adoptability testing complete
|
Hi cdt-test-dev -
Adoptability is complete, and I will
submit an update to the Master Test Plan once Bertina/Jeremy's update is
available. In the meantime, I am forwarding this report to the testing
community. Pardon me if it appears too much a hodge-podge of internal
reports.
There was some intended overlap between
Adoptability and Usability on Solaris. It was interesting to read
Bertina's findings on Usability on Linux sounded similar to mine.
- Brent
Adoptability
Product quality: YELLOW
Large-project users will likely
feel that they are using a project that has not been developed with them
in mind. Such users may be able to get stuff to work, but with work-arounds
and hacks that do not inspire confidence. CDT is also very sensitive
to the tools on your path and their versions, which diminishes its out-of-the-box
experience.
Cory’s questions from his SRS
are answered below.
Purpose
- Rapid adoption by a large team of developers
- Standard Makefile-driven project
- Individual developers focus on subset of
larger project
What we did
- Tested on Solaris (side-focus: Usability
on Solaris)
- Faked project “layers”
- Faked “project” Makefiles
- Build a sub-component instead of whole project
- Tried to load a subset of the entire project
- Compared against Emacs / Command-line
What I liked
- C/C++ Projects and Class Outline Views are
intuitive navigators.
- Make Targets View has potential to simplify
Makefile interface.
- Debug Perspective looks mature, feature-laden
- Solaris GUI (Motif) is better than Emacs
Defects
My top pain points:
- Expecting tools, and correct versions
of tools, to be installed without enforcing these restrictions. Particularly
gdb 5.2.1 (41402) and binutils 2.12?: addr2line, c++filt, nm (25816,36859,41404).
Also, Windows users continue to be confused by the error messages
when make or cygwin-make are absent.
- Better error parsing support is needed
(41381,39777, 41386) even for the default "best supported" tool-chain
(gcc). The result is that the error list in the Tasks view is not
always as informative as the C-Build log. In turn the C-Build log
is a poorer alternative to simple command-line output (39776, 41382).
- Users in a large project need to be
able to modify the built-in build targets (41393).
- No cut-and-paste between Eclipse and
other apps (41405).
As well, I wrote up Emacs-like Makefile
support as an enhancement request (41457).
The complete list of adoptability/usability
defects is below:
| Adoptability and Usability
|
| 25816
| Pressing "+" in the Navigator on
a binary hangs Eclipse [not mine]
|
| 36859
| Eclipse hands on closing a project with an
executable in it [not mine]
|
| 39343
| Unhelpful error message on importing overlapping
project
|
| 39615
| Untitled dialog ("Browse for folder")
on Solaris/Motif
|
| 39776
| OutOfMemoryError on Select All of large C-Build
log
|
| 39777
| Long build errors are not completely visible
|
| 40032
| Outline View is drawn twice on opening a
source-file
|
| 40033
| Outline View redrawn unnecessarily on editing
|
| 41381
| Linker errors unhelpful
|
| 41382
| C-Build log tabs should be 8 chars wide
|
| 41386
| Build errors are sorted such that Make errors
come first
|
| 41387
| Hover help on a breakpoint indicates location
of first breakpoint in the file
|
| 41393
| Make Targets view needs the ability to (right-click
and) specify the "default" build target.
|
| 41404
| hangs on close-project, or on expand-objectfile,
if missing addr2line
|
| 41402
| unhelpful error dialog if using old GDB version
|
| 41405
| no cut-and-paste between Eclipse and other
apps
|
| 41409
| Default fonts in Motif are fixed-width, ugly.
|
| 41410
| Default Text Font should be fixed-width on
Linux-GTK
|
| 41414
| Usability: Grayed-out text is illegible in
Motif
|
| 41415
| Progress bar for builds is rarely useful
|
| 41417
| Status bar does not provide make's arguments
|
| 41487
| Deselecting project in "Generic Source
Locations" in New Debug config caused crash
|
| 41457
| Equal or better Emacs' Makefile support |
Comparative Functionality:
Emacs has better Makefile support
(color-coding, navigation, specifying build targets). I've raised
an enhancement request to bring CDT up to its level (41457).
Error parsing is poor for link
errors. Make errors are frequent. User’s reaction is to go
to the build-log, which is not as good as a command-line log (39776,
41382).
Emacs also has a gdb interface
(untested), but Eclipse’s GUI interface to gdb (stack-traces, data, breakpoints)
is pretty nice once properly configured (version of GDB). Initial
reaction is positive, but some bugs appear (41387, 41487).
Build Targets
“How does a developer build only
his component of a large project?” Probably the easiest way is to
load in the entire project, turn off automatic builds, and use the Make
Targets View to create and build targets in your component's Makefile.
This could be better supported (41393), since you cannot use any
of the other ways to build your desired target. Alternatively, the
user can load sub-component projects instead (see below), but this is less
recommendable.
“How does a developer change from
building Component1 library to Component1 executable?” If the stub
executable’s code is uncontrolled but in the same component, the user
will likely have to change the controlled Makefile (and the the Make Targets
View). If the stub executable is in a different (uncontrolled) component,
the user needs to write an entire Makefile, and set Make Targets, and Project
dependencies, but the library’s files are unchanged.
When adopting an unmanaged Makefile,
the ability to modify the default build targets (Ctrl-B, “make all”,
“make clean all”) is extremely important; “all” and “clean” should
appear as default Make Targets in that view (41393).
At present, the only purpose of
specifying Project References seems to be for “Rebuild All” purposes.
Loading sub-component projects
“If the application is large,
but the user’s development environment is a small subset, can they load
just the subset?” Yes, the user can use a separate workspace for
the subset and for the entire project, each pointing to different directories
within the same project structure. This is not an officially supported
workflow, but rather a work-around of Eclipse limitations on resource hierarchy.
It feels like a work-around (39343) and feels ugly and risky: switch
workspaces and you lose your breakpoints, make targets view, other info.
You also leave extraneous .cdtproject and .project files (and possibly
other artifacts) around, with potential for side-effects in source-control
or in switching workspace.
Multiple target environments
“How does the user build for VxWorks?
As a test (stub) executable?”
Remote target debugging not tested.
Building on various targets is likely solvable with correct Makefile
configuration.
Source control
A gray area requiring more time,
particularly after 1.2 features (search databases, generated Makefiles)
are finished.
Source-controlling .cdtproject
and .project files is probably OK, not contentious.
Attachment:
Adoptability.xls
Description: MS-Excel spreadsheet
