[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] Build model proposal
|
All,
Following is a proposal for dealing with the build model in the next
major CDT release. It's based on, but not identical to, work we've done
here at TimeSys for our soon-to-be-released TimeStorm IDE.
I know that others (QNX and Tensilica, in particular) have also done
work in this area. From the recent flurry of messages on the mailing
list, I think that we all have fairly similar (or at least, compatible)
ideas about the build model.
One issue that is not addressed in this proposal is build script
generation (ant build files, Makefiles etc.) I think that given a good
build model, build script generation becomes a fairly straightforward
process, and one that can be discussed seperately once the abstract build
model is defined.
I look forward to your comments... hopefully, even if this model is
waaaaaay off the mark, it will at least get us all to start looking at
and discussing the details of the build model.
-Samrobb
------------------------------
Proposal for a CDT Build Model
------------------------------
At the most basic level, the problem is how to turn a particular source file
into an object file. The first piece of information needed is the type of
file (whether it's C source, assembly source, etc.) Once that is known, it
is possible to determine which tool (gcc, gas, etc.) is used to compile the
file.
(For now, I'm going to skip the problem of knowing what parameters to pass
to the tool in order to compile a particular file. More on that later.)
Eclipse provides a mechanism for associating editors with a file type ( via
Windows > Preferences > Workbench > File Associations). What's missing is
a mechanism that associates a file type with the particular tool that is
used to compile those types of files.
In TimeStorm, we provided a file mapping manager (FMM) that could be
queried for the tool identifier that matched a particular file type. For
example, when passed a reference to a C source file, this manager would
return a unique identifier for the type of tool used to compile C source
files.
[ Extension point proposal ]
1) XP that declares a known file type mapping
(ex, "*.c" --> "C Source File")
2) XP that declares a known tool
(ex, "CC" --> "C Compiler")
3) XP that declares a file type/tool association
(ex, "C Source File" --> "C Compiler")
These would be used by an implementation of a file mapping manager. The
FMM implementation would include a Preferences UI similar to the standard
eclipse "File Associations" UI that would give users basic CRUD (create,
replace, update, delete) abilities wrt file --> tool mappings. Not mapping
a file type directly onto a tool allows users to define change or define
additional mappings as needed.
Having the FMM Returning a unique identifier instead of an executable name
made it possible to introduce and support the concept of multiple toolchains.
A toolchain consists of a group of related tools (ex, GNU tools for x86, GNU
tools for PowerPC, etc.) A toolchain manager is responsible for discovering
and making available the list of installed toolchains, and exposing what
tools are available as part of that toolchain.
[ Extension point proposal ]
1) XP that declares a toolchain provider.
The simplest toolchain provider is one that simply returns information on
the installed native toolchain, if it's present. On Linux, for example,
this provider would return information about the native versions of gcc,
gdb, etc. installed on the system. A second provider would allow the user
to define their own toolchains, using a Preferences UI panel. ISVs could
use this extension point to expose additional toolchains to CDT. As an
example, TimeSys makes use of a configuration file (/etc/timesys.conf) to
identify toolchain locations and descriptions. Other vendors could use
similar methods.
So, given a source file, the steps for determining which tool to use while
compiling it are roughly:
1) Obtain a reference to the file resource.
2) Pass the file reference off the file type manager.
3) The file type manager returns the identifier for the tool that
should be used to compile the file.
4) Determine which toolchain is associated with the project.
5) Pass the toolchain manager the tool identifier.
6) The toolchain manager returns an interface to the tool.
7) The tool is used to generate the command needed to process the file.
Step 4 indicates a problem... there needs to be a way to indicate which
toolchain provides the tools that will be used to build the source files
that make up a project. I'm going to gloss over that and presume, for
now, that a project is associated with a single toolchain in some manner,
and that it is possible for users to easily specify and change which
toolchain is used to compile a particular project.
In step 7, there is now the problem of knowing what parameters to pass to
the tool in order to process a particular file. That information may be
specified at the project level or on a per-file basis, in the event that a
user wants to override the project settings for a specific file. While
these parameters are associated with a resource element (project or file),
the UI used to edit them is dependent on the tool that is used to process
a particular file.
Many IDEs use a tabbed dialog to represent project and file settings; only
those tabs that are applicable are displayed. For example, when specifying
the parameters for a C source file, the tabs for the C pre-processor and C
compiler should be displayed, but not a tab for setting linker options.
[ Extension point proposal ]
1) XP that describes a tool settings panel
2) XP that describes a project settings panel
A tool should indicate which UI element (tool settings panel) it uses for
managing it's settings. As a default implementation, the simplest such UI
element would be a panel containing a text box for the user to enter
parameters in. ISVs could provide interfaces that map well to their
particular tools.
Project and per-file tool parameters would be stored within the workspace as
a dot file (similar to .project, .cdtproject, etc.) As most tool options
map to simple text strings (or, perhaps, a collection of text strings)
storage can use a mechanism similar to that used by Eclipse to store launch
configurations.
Projects are a special case, in that there are certain options (linker
settings, for one) that apply only to a project. Additionally, while there
is generally a single straightforward method of turning a source file into
an object file, there are multiple distinct ways of combining source files
into some kind of product. Shared libraries, static libraries, and plain
executables all have very different link stage requirements.
[ Extension point proposal ]
1) XP that declares a project type
2) XP that declares a UI pane for a project type.
A project has an associated project type that defines how to produce (link)
the generated object files together to produce a final output file. This
really is a level of indirection on top of the toolchain - the project type
determines which tools from the toolchain are used, and how they are used,
to generate a final product for a project.
Now I'll interject something that's part of our requirements: the ability
to have multiple build configurations for a project. Each build config
specifies the project- and file-level settings used to build the project.
Since settings are associated with a particular toolchain, each build
config is associated with a toolchain as well. Finally, the project has
one or more build configs, and the concept of an "active configuration",
which is the one that is used when the user builds the project.
Anyone who has used MSVC or a similar compiler should be familiar with the
idea of build configs. Aside from the obvious (the ability to generate
debug/release/profile builds for a single project), build configs are
valuable to any developer who needs to potentially build the same project
using different library, architecture, or OS targets.
The simplest configuration manager is one that allows for a single config,
containing a reference to the toolchain to use when building the project
and the project- and file-level settings for the project. ISVs can provide
their own build configuration manager to reflect the particular requirements
of their users. Because of the way that the presence of multiple build
configs impacts things like Makefile management, the build object model,
debugging, etc., the core CDT code should be engineered to be aware of the
potential for multiple build configs on a project, even if the default
implementation is to support a single build config.
[ Extension point proposal ]
1) XP that declares a build configuration manager for a project
