[cdt-dev] MBS Working group meeting summary

[Sean Evoy <sevoy@xxxxxxxxxx>]

Hi All,
After a bit of a delay, here is the
summary of the notes I took during the two conference calls we held to
review the MBS 3.0 proposal from Leo. A copy of this summary in MS Word
format and HTML will be attached to the bugzilla report momentarily.


Introduction
During the July 7 CDT conference call,
it became clear that many partners were planning, or already using, their
own build systems rather than concentrating on enhancing the current CDT
builders. While this is understandable given the importance of building
to end users and the complexity of designing a system that can meet the
needs of such a diverse group, our focus is developing a world-class IDE.
Surely, part of that effort must include a common way to integrate the
build step for all of our partners. Despite the difficulties, the benefits
of a consistent, “insanely good” end-user experience and stable interfaces
on which the internals of the CDT can rely make it worth our while to solve
this challenge.

The managed build system (MBS) has had
about a year of feedback from end users and ISVs, so it seemed like a good
time sit down as a group and discuss what features the MBS will need, how
we intend to get to there, and when. It was proposed that we hold one or
more conference calls dedicated to this subject, with a view to finalizing
the architecture of the MBS and establishing a rough roadmap for future
releases. 

During the last development cycle, Leo
Treggiari from Intel took the initiative and proposed a set of major design
enhancements for the MBS. The initial proposal and subsequent discussion
is posted in the CDT Bugzilla entry 68232. Other than a request to consider
cmake as the build utility, the overall feedback was that we should be
concentrating on advancing the current architecture to handle requirements
rather than dynamiting everything and starting over. It made sense then,
to use the conference calls to review the high-level, detailed requirements
of the proposal.

The first call took place at 10:30 EDT
on July 27, the second on July 29. Both calls were well attended with participants
from IBM, Intel, MontaVista, PalmSource, QNX, Red Hat, Rockwell Collins,
Texas Instruments, TimeSys, and WindRiver. This document contains a summary
of the notes I took during those two calls. Since we reviewed the substance
of Leo’s proposal point by point, the notes are organized by the sections
in that document. If I have missed anything of significance, please let
me know and I will update this summary.

User Model
Some broad comments were made during
the discussion of the user model. The overall discussion focused on core
features that could be reused to support the build model, and how/where
ISVs and users could customize settings. 

It was suggested that the work done
on file extension mapping, currently employed by the CDT to decide what
editors to open a file with, could be reused to support mapping one or
more file extensions to a logical type of tool. The ISV could then supply
a specific instance of the logical tool via the XML definition.

Another participant raised the point
that relying exclusively on the extension of a file could lead to problems
with certain types of source files, specifically for assembly language
source files where there are so many “flavours” of assembly syntax and
a corresponding number of potential tools to choose from. To support this,
there may be a need to add some sort of further discriminator in a tool
definition.

It was also pointed out that the current
organization of the managed build system, where the default tool chain
is supplied with the feature, makes it difficult to integrate tools that
completely replace this definition. We really need to reorganize the Gnu-specific
tool definitions into their own package that can be removed by an ISV if
desired. 

Finally, there was consensus that a
guiding principle should be that mappings in the XML should be kept as
generic as possible and specific settings should be tweaked by the user
or installed products via the preferences. Most participants seemed to
want to supply their customizations via extension points.

Detailed Requirements

Project and Project Types
Regarding requirement 5, it was pointed
out that the term macros implies an arbitrarily complex statement that
can evaluate to anything. This might be difficult to support with so many
ISVs extending the MBS. It was suggested that we could use the path and
string variable feature of Eclipse. In the end, the consensus seemed to
be that integrators need a common way to define things like the path to
their SDKs, so perhaps reserving certain variables that can be overridden
by a tool-chain is a better approach than supporting the open-ended concept
of a macro. 

Regarding removing the requirement on
users to specify whether a project is C or C++ (item 9), it was pointed
out that there is a technical requirement for the scanner to know whether
to treat a compilation unit as C or C++. If the clients of the scanner
can use the file extension mapping feature rather than the project nature
to “figure it out” on a file-by-file basis, then perhaps we could avoid
forcing the user to choose. If not, then this might be a difficult requirement
to realize. 

Configurations
The balance of the discussion regarding
the configuration requirements focused on the UI changes that are needed
to see what configuration was active, and to support building a configuration
this is not active. It was also pointed out that being able to multi-select
configurations for build would be a nice to have feature.

Tool Chains
A discussion took place over whether
or not a default makefile generator could be created for the managed build
system. While no make “dialect” was explicitly requested, it seems pretty
clear that a POSIX make file generator that can handle the basic build
use-cases would be helpful for ISVs who do not want to use Gnu make and
are not yet ready to write their own generator. It was pointed out though,
that no single makefile generator would be able to handle every toolchain
that can be described in the build model. 

It was pointed out that users often
install new versions of a toolchain that differ in very small ways (a new
option or minor bug fix). However, users may want to build a project, or
parts of a project, using different versions of the same tool. It would
be useful if there were some way to visually swap toolchains. This was
also an issue for ISVs who have to support variants of the same toolchain
that differ only in the wrapper that is called to invoke certain tools.


On the point of swappable toolchains,
it was mentioned that supporting some way for ISVs to dynamically discover
tools would be handy. This could simply be an extension point that the
ISV supplies the actual implementation logic for.

Tools
We had a brief discussion about requirement
8. It was pointed out that we had to keep internationalization and localization
in mind so that we could always rely on the header output to be recognizable
if we use this strategy. Another participant mentioned that the output
was too verbose, and asked whether we could tone it down or redirect to
a file, reserving the build console for errors. 

Regarding items 13 and 14, there was
general consensus that we should get rid of the round-trip option feature.
Basically, it is a neat feature, but with increasing numbers of options
and the proposed model changes, supporting this is going to become very
difficult. Further, option ordering in the widget is not respected, so
it leads to user confusion and disappointment.

There should be some way for individual
developers to specify that a tool is not installed in the default location.
Currently, this can be done by specifying an absolute location in the tool
command widget. However, this can lead to sharing problems since the change
is stored in a file that is shared via the CM system. Overriding this in
the preferences would make it easier to support for individual developers.

Options
We discussed whether we needed more
option types to cover off the kind of options that ISVs will be supporting.
There was no real consensus reached on this point beyond a cautious maybe.


We did agree that we needed some way
to describe the formatting of an option output via a formatting string.
We discussed the need to be able to specify (at least) a partial ordering
of options for toolchains that are order-sensitive.

We discussed what we need for help support.
First, just about every model element might have some sort of help associated
with it, so the discussion was not limited to options. 
We would need to have some way for providers
to hook their own help sources into the F1 help system, assuming that not
everyone can use the Eclipse help system. 

Resources
A very interesting discussion about
how to deal with linked resources in the context of automated project building
took place. It was pointed out that a linked resource might map to a different
location on a centralized build machine than it would on a user machine,
and relative paths will be worse than absolute paths in this case. Another
wrinkle was added when someone pointed out that not every build machine
would be capable of running Eclipse, so how a makefile generator deals
with linked resources should be looked at in greater detail.

The build system should support option
setting overrides at the resource level in a way that does not require
the user to re-enter every other option setting that is common with the
project defaults. In other words, do not force the user to reenter includes
paths and defines if they just want to compile a set of resources with
debug symbols.

Building
There are a number of subtle requirements
that are not currently supported by the build system that were discussed.
First, being able to build a single resource is a key requirement. We should
support a compile-only build, something that will require some support
from the Eclipse core. As mentioned in the configuration discussion, building
more than one configuration, or building the configuration that is not
the selected configuration would be a powerful enhancement. 

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada