[cdt-dev] Thoughts on Targets

["Thomas Fletcher" <thomasf@xxxxxxx>]

Folks,

  Sorry that this was so long in coming, I started writing this up on an
airline flight
coming back into Ottawa and never quite got it to the point where I was
happy
with it ... but rather than wait I think that I should get it out onto the
list now so
that we can start talking about it.

Thanks,
  Thomas

---

Why do we need targets (CDT oriented)

-Build environment integration
 - To avoid confusion, a build target in this context should not be confused
with
a make target.
 - Certain tools will have limited/differing capabilities which are only
available for
certain platforms.  This information is however not necessarily tied to a
specific
runtime target instance.  That is that there is a one to many mapping of
possible
build targets to runtime targets.  Build targets will generally contain
information
which is static such as operating system, processor or processor family or
perhaps
even a specific hardware configuration (ie a specific evaluation board or an
extensible CPU).
 - A build target would contribute to the build configuration information.
The
build configuration contains information such as defines, include paths, pre
and
post pre-process,compile and link activities.

-Launch integration
 - The launch configuration is one of the consumers of the build process
results.
It may require information about the environment so that it can provide the
appropriate default configurations based on the selections provided by the
user.
Launch configurations today make use of target specific information to
assist
with binary selection, dependant library selection, runtime environment
variable
configurations, remote file transmission and remote agent selection.
 - Runtime targets are not always accessible.  That is that the target
configuarion
should be able to provide both live information when it is available and
"off-line"
content when it is not.  Not all target information may be available
however.

What does a target need to do?

- It must be straightforward to configure by users.
- It must be easy to extend with additional environment specific attributes.
- It must be persistable and have the ability to be stored under version
control
- ... <Other thoughts from other people>

Up for discussion:

-Build targets vs Runtime targets?
 Should there be a seperate build target definition which is relatively
static
 and a runtime target configuration which is more dynamic and represents a
specific
 instance of a runtime target (which may or may not be accessible)? Would a
single
 target configuration/definition which encompasses all attributes be easier
for
 users and developers to understand?

 In the seperated model I would see something along the lines of a
configuration
 system which would be:
 Build Target: <Generally Vendor Supplied/Autoconfigured, extension point>
  - Name: Neutrino MIPS Build    <-- For UI purposes
  - OS: Neutrino      <-- Vendor advertised
  - Processor: MIPS   <-- Map this to some pseudo standard convention
  - Endian: little

 Runtime Target: <Generally user defined/configured>
  - Name: Malta1
  - Build: Neutrino MIPS Build
  - Connection: <Some yet to be defined interface for accessing target>
                <This should be an extension point>

  - Name: Malta2
  - Build: Neutrino MIPS Build
  - Connection: <...>

-What should the model look like, how should it be accessed?
 I feel that adapting the data model which is used by the launch
configuration would
 make the most sense.  In this model there is a "configuration" which simply
has a
 number of named attributes associated with it and is capable of being
exported to
 the workspace, but in general is not a visible entity except through the
launch
 configuration dialogs.


<Lots more discussion required>