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

["Douglas Schaefer" <dschaefe@xxxxxxxxxx>]

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)
Doug




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


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

Subject
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.

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 
- ...
 
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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev