Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Target Discussion (was [cdt-dev] Next CDT Conference Call)

Thanks, Thomas.  The target model and the managed make build model need to 
be separate but the build model makes use of the target model.  To be 
complete, I will take a stab at formalizing your requirements and publish 
a combined proposal.

The demand for this thing seems to be getting pretty hot.  I will have it 
out by the end of day Wednesday.

Happy Canada Day! (which is Tuesday for our non-Canadian friends)

Thomas Fletcher <ThomasF@xxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
06/30/2003 04:46 PM
Please respond to

"'cdt-dev@xxxxxxxxxxx'" <cdt-dev@xxxxxxxxxxx>

Target Discussion (was  [cdt-dev] Next CDT Conference Call)

> -----Original Message-----
> From: Phil Muldoon [mailto:pmuldoon@xxxxxxxxxx]
> Sent: June 30, 2003 3:28 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: RE: [cdt-dev] Next CDT Conference Call
> In reference to Chris Songer, Anthony Green and Doug's comments on the
> target system (objdump/add2line) can we have a quick round up there -
> and non native toolchain's target support? Doug mentioned something
> along the lines of sketching out a target model there, and not
> overloading the build model. Though this might already be 
> addressed in 
> "Discussion of other framework/features" agenda item

Just as a refresher ... and now that I see that Doug is back =;-)
I'll repost my initial blurb of thoughts on targets.  Not being
fully into the build planning, but fully working with cross hosted
development tools and embedded system targets , I might come at it 
with a different slant.


Why do we need targets (CDT oriented)

-Build environment integration
 - To avoid confusion, a build target in this context should not be 
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
runtime target instance.  That is that there is a one to many mapping of
build targets to runtime targets.  Build targets will generally contain
which is static such as operating system, processor or processor family or
even a specific hardware configuration (ie a specific evaluation board or 

extensible CPU). 
 - A build target would contribute to the build configuration information.
build configuration contains information such as defines, include paths, 
post pre-process,compile and link activities.

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

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 
- It must be persistable and have the ability to be stored under version
- ...
Up for discussion:

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

 In the seperated model I would see something along the lines of a
 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 
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
 configuration dialogs.
cdt-dev mailing list

Back to the top