1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="MakeProjectCreator.css" charset="ISO-8859-1"
type="text/css">
<title>MPC: WB30 Project Type</title>
</head>
<body>
<div>
<h1 class="Head1">WB30 Project Type documentation</h1>
<div>
<h3 class="Head2">Background/Abstract</h3>
<li class="Body">The <em>WB30 Project Type</em> generates project files
utilizable by Wind River Workbench, version 3.0. Workbench is built
on the Eclipse platform and inherits many of its features. In this
document, "eclipse" is used at times to describe features common to
both eclipse itself and workbench.
The project type generates workbench projects from generic mpc
files. These workbench projects can then be imported into a user's
workspace and built using the workbench "managed flexible build".</li>
<li class="Body">MPC's WB30 Project Type currently supports Linux
and Windows as both host and target platforms. It can be extended to
support other platforms as well.</li>
</div>
<div>
<h3 class="Head2">Usage</h3>
<p class="Body">
For every <em class="Code">project <var>myprojname</var> { }</em> in mpc files, the
WB30 project type
generates a corresponding "workbench project" directory of the form
<em class="Code">wb_<var>myprojname</var></em>. The WB30 Project Type
uses Eclipse's <em>linked resource</em> feature to work around
Eclipse's usual requirement that source files reside inside the Eclipse
project directory. However, the linked resource feature also comes with
restrictions; see <a href="#fullpath">the note</a> for details.
</p>
<h4 class="Head5">Generic workflow</h4>
<p class="Body">Presuming .mpc files already exist:</p>
<ol>
<li><p class="BodyNoLead">Generate projects using <em class="Code">-type wb30</em>.</p></li>
<li><p class="BodyNoLead">Import projects into a Workbench workspace. From within Workbench
(preferably an otherwise-empty workspace) select
<strong>File->Import...</strong> and perform the following actions:
<ol type="a">
<li><p class="Body">Choose <strong>General->Existing Projects Into
Workspace</strong> and click <strong>Next</strong></p></li>
<li><p class="Body">In "Select Root Directory:" text field, enter the full path
to the MPC workspace.</p></li>
<li><p class="Body">Workbench will scan all the subdirectories looking for existing
projects.</p></li>
<li><p class="Body">
<strong>Be sure that the checkbox next to <em>Copy projects
into workspace</em> is <em>UN</em>checked.</strong>
Copying projects into the workspace unnecessarily duplicates
files, plus we have found that Workbench can get confused with file
paths sometimes (though sometimes it will work).</p></li>
<li><p class="Body">Click <strong>Finish</strong> to proceed with the import.</p></li>
</ol>
</p>
</ol>
<h4 class="Head5">Building A Project</h4>
<p class="Body">
To build a project or set of projects, select the project (or
projects) in the <em>Project</em> pane, then select
<strong>Project->Build Project</strong>.
</p>
</div>
<div>
<h3 class="Head2">Platforms and Buildspecs</h3>
<p class="Body">
The default platform for WB30 is called "Native" and corresponds to creating
a project in Workbench using File -> New -> Native Application Project.
Although this method doesn't have (in workbench) any direct support for
building shared libraries, MPC does generate projects that pass the correct
compiler and linker flags to create shared (dynamic) libraries. Selecting
static or shared libraries with WB30 works the same as with any other MPC
project type.</p>
<p class="Body">
The alternative platform, "VxWorks" can be selected by passing the option
<em class="Code">-value_template platform=VxWorks</em> on the mwc.pl command line.
Currently the VxWorks support is inherited from the existing
<em class="Code">-type wb26</em> template, so it may need some more work before it is
production-ready. Note that the wb26 template supported only DKM projects for
VxWorks (Downloadable Kernel Modules).</p>
<p class="Body">
Each platform includes a list of supported buildspecs, and a single default
buildspec. For the "Native" platform, the list of supported buildspecs is:
</p>
<ul>
<li><p class="Body">Linux_gnu_native_3.x_4.x</p></li>
<li><p class="Body">Windows_gnu_native_3.x_4.x</p></li>
</ul>
<p class="Body">
Users can select the list of buildspecs by passing the option
<em class="Code">-value_template buildspecs=<specs></em> on the mwc.pl command
line, where <specs> is replaced by the buildspec value or values.
Multiple values are separated by spaces (with the entire specs string
enclosed in quotes). Similarly, the default buildspec can be selected with
<em class="Code">-value_template default_buildspec=<spec></em>.</p>
<p class="Body">
New buildspecs (or even platforms) can be added by either editing the file
<em class="Code">$MPC_ROOT/templates/wb30dll.mpt</em> (if the modification will be
submitted back to the public MPC repository), or creating a file named
<em class="Code">user_wb30dll.mpt</em> anywhere on the MPC -include search path.
Within either of these files, create a scope for the platform/buildspec and
use assignment statements within that scope to set the various template
variables. The existing buildspecs serve as the best examples.</p>
</div>
<div>
</div>
<div>
<h3 class="Head2">Notes</h3>
<ol>
<li>
<p class="Body">
MPC doesn't directly generate Workbench workspaces, because they depend
on an unknown binary file format that it can't generate. Instead of
generating files that can be loaded as a Workbench workspace, MPC
generates two files representing the workspace:
</p>
<ol>
<li><p class="Body">wb30projects.lst</p></li>
<li><p class="Body">org.eclipse.core.resources.prefs</p></li>
</ol>
<p class="Body">
wb30projects.lst contains comment lines (starting with #) followed by
one line per project, listing the full path to the .project file.<br/>
org.eclipse.core.resources.prefs also begins with comment lines
(starting with #) followed by the contents of one of the files from
Eclipse's workspace format, specifically:
<em class="Code">.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs</em>
Unfortunately, this file alone is not enough to actually constitute a
workspace because Eclipse uses other binary files in this .settings
directory.
</p>
</li>
<li><p class="Body"><a name="fullpath"></a>WB30 uses Eclipse's <em>linked resource</em>
feature to work around the usual requirement that
all source code reside in Workbench project directories. These
act similar to symbolic links. While convenient so that a
developer is not required to conform to Workbench's directory
layout, it comes at a price: the target of the link must be
specified as a full path. The consequence of this restriction is
that, once the WB30 projects get generated, the source directory can
not move in the filesystem without re-generating the projects.</p></li>
<li><p class="Body"><a name="remove_projects"></a>MPC's WB30 Project Generator
creates directories named <em class="Code">wb_*</em> for projects.
To remove all WB30 projects from a
directory hierarchy, on Linux you can use a command such as:</p>
<blockquote>
<p class="Code">$ find . -name 'wb_*' -type d | xargs rm -rf</p>
</blockquote>
</li>
</ol>
</div>
</div>
<hr>
</body> </html>
|
