Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] MBS Working group meeting summary

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.

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.

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.

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.

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.

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.

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

Back to the top