|
1 .. index:: |
|
2 module: Configuring Raptor (SBS) |
|
3 |
|
4 ======================== |
|
5 Configuring Raptor (SBS) |
|
6 ======================== |
|
7 |
|
8 .. contents:: |
|
9 |
|
10 This document describes requirements and how to run sbs builds using helium. Now it is |
|
11 possible to pass directly pass all the raptor input directly and there are no mapping of |
|
12 raptor parameter specific to helium. |
|
13 |
|
14 |
|
15 SBS Requirements |
|
16 ----------------- |
|
17 |
|
18 Before starting the build, SBS needs to be updated for s60 related changes, please follow the instructions from the link below, |
|
19 |
|
20 `How to Build Raptor <http://s60wiki.nokia.com/S60Wiki/How_To_Build_With_Raptor>`_ |
|
21 |
|
22 1. SBS_HOME environment variable needs to be set |
|
23 2. PATH environment variable needs to be updated with SBS related exe:: |
|
24 |
|
25 path(SBS_HOME\\BIN;SBS_HOME\\win32\\mingw\\bin;SBS_HOME\\win32\\msys\\bin) |
|
26 |
|
27 3. RVCT requirement for raptor is 22_686 or higher, in IDO config / product config batch file the env variable needs to be set to `HLM_RVCT_VERSION=22_686` |
|
28 |
|
29 For Example: :: |
|
30 |
|
31 set HELIUM_HOME=E:\Build_E\ec_test\helium-trunk\helium |
|
32 set PATH=e:\svn\bin;E:\sbs\bin;c:\apps\actpython;%PATH% |
|
33 set SBS_HOME=E:\sbs |
|
34 set MWSym2Libraries=%MWSym2Libraries%;C:\APPS\carbide\x86Build\Symbian_Support\Runtime\Runtime_x86\Runtime_Win32\Libs |
|
35 set TEAM=site_name |
|
36 |
|
37 (Note: For IDOs, these environment variables are set automatically, for S60 option is proposed). |
|
38 |
|
39 Required SBS input for Helium |
|
40 ------------------------------ |
|
41 |
|
42 SBS Input consists of SBSInput and SBSBuild types: |
|
43 |
|
44 1. SBSInput - SBS Input stores the list of raptor arguments both the sbs options and |
|
45 sbs make options. Nested sbs input option is also possible, for details please see the |
|
46 antdoclet information for sbsInput. |
|
47 |
|
48 2. SBSBuild - SBS Build is the collection of SBSInput. Each SBSInput refering within |
|
49 SBSBuild corresponds to a single invocation of raptor with the corresponding sbs arguments |
|
50 refered within the sbsInput. Each sbsInput refered within SBSBuild roughly corresponds to |
|
51 the abld commands associated with corresponding abld configurations. <configuration> </configuration> |
|
52 is corresponds ot SBSBuild. This is there only for backward compatibility and will be removed |
|
53 once the mighration is completed for schema 3.0, in which case, abld mapping of configuration |
|
54 is not required and sbsInput could be directly used. Example is as below, |
|
55 |
|
56 .. code-block:: xml |
|
57 |
|
58 <hlm:sbsbuild id="sbs.dfs_build_export"> |
|
59 <sbsInput refid="dfs_build_export_input" /> |
|
60 </hlm:sbsbuild> |
|
61 |
|
62 |
|
63 1. To run using SBS mode (schema 1.4.0) |
|
64 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; |
|
65 |
|
66 List of SBSInput one to one mapping with corresponding abld commands mapped for a configuration. |
|
67 |
|
68 example is below, |
|
69 |
|
70 .. code-block:: xml |
|
71 |
|
72 <!-- tools common sbs options --> |
|
73 <hlm:sbsoptions id="commonSBS"> |
|
74 <arg line="-k" /> |
|
75 </hlm:sbsoptions> |
|
76 |
|
77 <hlm:sbsoptions id="exportSBS"> |
|
78 <argset refid="commonSBS" /> |
|
79 <arg line="--export-only" /> |
|
80 </hlm:sbsoptions> |
|
81 |
|
82 <!-- sbs input for export --> |
|
83 <hlm:sbsinput id="export-sbs"> |
|
84 <sbsoptions refid="exportSBS" /> |
|
85 </hlm:sbsinput> |
|
86 |
|
87 <hlm:sbsbuild id="sbs.dfs_build_export"> |
|
88 <sbsInput refid="dfs_build_export_input" /> |
|
89 </hlm:sbsbuild> |
|
90 |
|
91 Assuming there is a dfs_build_export schema configuration 1.4.0 system definition file. |
|
92 Then there should be a corresponding <hlm:sbsbuild> type defined prefixing with sbs |
|
93 as sbs.dfs_build_export as above which contains a reference to sbsinput. The sbsInput |
|
94 contains actual raptor commands equivalent to abld commands to be executed for that |
|
95 configuration, in this case it is referring exportSBS, which in turn referring to commonsbs |
|
96 so finally the command generated would be |
|
97 |
|
98 .. code-block:: xml |
|
99 |
|
100 sbs -k --export-only |
|
101 |
|
102 This command is executed for all the components specified in the dfs_build_export |
|
103 configuration. |
|
104 |
|
105 No change from the configuration is required, except the new raptor input needs to be imported. |
|
106 |
|
107 2. To run using SBS mode (schema 3.0.0) |
|
108 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; |
|
109 |
|
110 For schema 3.0, required inputs are, |
|
111 a. sbs arguments |
|
112 b. package definition files |
|
113 c. filters to filter the component (check sysdefFilterSet under Helium Antlib documentation) |
|
114 d. patternset - specifying specific set of layers to be executed (deprecated, will be replaced by id filtering). |
|
115 |
|
116 As Raptor does not support yet schema 3.0 parsing, the system definition file |
|
117 should be downgraded before being passed to the tool. This feature is controlled by |
|
118 the ***sbs.downgrade.sysdef.enabled*** boolean property. |
|
119 |
|
120 Filtering can be configured by defining a hlm:sysdefFilterSet type with a specific reference id based on the following |
|
121 naming convention: sbs.filters.<configuration_name> |
|
122 |
|
123 This example shows how to configure a filterset for the build_export configuration: |
|
124 |
|
125 .. code-block:: xml |
|
126 |
|
127 <!-- sbs input for export --> |
|
128 <hlm:sbsbuild id="sbs.build_export"> |
|
129 <sbsInput refid="dfs_build_export_input" /> |
|
130 </hlm:sbsbuild> |
|
131 |
|
132 <hlm:sysdefFilterSet id="sysdef.filters.build_export"> |
|
133 <filter filter="!test,os" type="has" /> |
|
134 </hlm:sysdefFilterSet> |
|
135 |
|
136 With a similar configuration approach a set of layer can be selected or excluded, by defining a patternset following this naming convention: |
|
137 sbs.layers.<configuration_name> |
|
138 |
|
139 Example: |
|
140 |
|
141 .. code-block:: xml |
|
142 |
|
143 <patternset id="sysdef.layers.build_export"> |
|
144 <include name="mw" /> |
|
145 <exclude name="os" /> |
|
146 </patternset> |
|
147 |
|
148 |
|
149 Customizing raptor input |
|
150 ------------------------ |
|
151 |
|
152 Different scenario the user might need to provide the raptor inputs, (required to map raptor |
|
153 commands for abld configuration which is not there in the default raptor input xml file, |
|
154 want to override the default raptor input to pass additional parameters), below section covers |
|
155 how these can be customized. |
|
156 |
|
157 Mapping raptor commands for new configuration from system definition file (1.4.0) |
|
158 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; |
|
159 |
|
160 First step is to identify the abld commands executed by the new configuration. Correspondingly the |
|
161 raptor commands need to be identified for that. Then need to check from the common raptor input |
|
162 is there any input which can be reused. If any raptor input could be re-usable, the just refering |
|
163 that input and adding additional arguments would provide the exact raptor command arguments to be |
|
164 executed. |
|
165 |
|
166 |
|
167 For example, if the new configuration for which the raptor command input is to be created is, |
|
168 os, which is not there in the default raptor input, then abld commands executed are |
|
169 (to be simpoer - bldmake, export, tools_rel, winscw, armv5). The corresponding raptor input would |
|
170 be |
|
171 |
|
172 |
|
173 .. code-block:: xml |
|
174 |
|
175 <hlm:sbsinput id="build_input_os_export"> |
|
176 <sbsInput refid="export-${build.system}" /> |
|
177 <sbsOptions> |
|
178 <arg name="--logfile" value="${compile.log.dir}/${build.id}_export_os_build.log" /> |
|
179 <arg name="--makefile" value="${temp.build.dir}/${build.id}_export_os_build" /> |
|
180 </sbsOptions> |
|
181 </hlm:sbsinput> |
|
182 |
|
183 <hlm:sbsinput id="build_input_os_tools"> |
|
184 <sbsInput refid="tools-${build.system}" /> |
|
185 <sbsOptions> |
|
186 <arg name="--logfile" value="${compile.log.dir}/${build.id}_tools_rel_os_build.log" /> |
|
187 <arg name="--makefile" value="${temp.build.dir}/${build.id}_tools_rel_os_build" /> |
|
188 </sbsOptions> |
|
189 </hlm:sbsinput> |
|
190 |
|
191 <hlm:sbsinput id="build_input_os_winscw"> |
|
192 <sbsInput refid="winscw-${build.system}" /> |
|
193 <sbsOptions> |
|
194 <arg name="--logfile" value="${compile.log.dir}/${build.id}_winscw_os_build.log" /> |
|
195 <arg name="--makefile" value="${temp.build.dir}/${build.id}_winscw_os_build" /> |
|
196 </sbsOptions> |
|
197 </hlm:sbsinput> |
|
198 |
|
199 |
|
200 <hlm:sbsinput id="build_input_os_armv5"> |
|
201 <sbsInput refid="armv5-${build.system}" /> |
|
202 <sbsOptions> |
|
203 <arg name="--logfile" value="${compile.log.dir}/${build.id}_armv5_os_build.log" /> |
|
204 <arg name="--makefile" value="${temp.build.dir}/${build.id}_armv5_os_build" /> |
|
205 </sbsOptions> |
|
206 </hlm:sbsinput> |
|
207 |
|
208 The default raptor input for each build target (tools, winscw, armv5) are reused here and just the |
|
209 log file names are changed. |
|
210 |
|
211 Next the sequence of command execution needs to be defined for the corresponding os confoguration as below. |
|
212 |
|
213 .. code-block:: xml |
|
214 |
|
215 <hlm:sbsbuild id="sbs.os"> |
|
216 <sbsInput refid="build_input_os_export" /> |
|
217 <sbsInput refid="build_input_os_tools" /> |
|
218 <sbsInput refid="build_input_os_winscw" /> |
|
219 <sbsInput refid="build_input_os_armv5" /> |
|
220 </hlm:sbsbuild> |
|
221 |
|
222 For configuration name os in the system definition file, it will take the list of raptor input |
|
223 as defined with sbs.os, then it will execute each sbsinput as separate sbs calls with the arguments |
|
224 extracted from the corresponding reference id. |
|
225 |
|
226 Overriding default raptor arguments |
|
227 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; |
|
228 |
|
229 In case the default argument is not enough for the user requirements, this could be overriden by |
|
230 redefining the reference of a particular sbsoptions will provide the user to change the arguments. |
|
231 |
|
232 For example, if the user just wants to pass debug flag for armv5 raptor inputs, the raptor input |
|
233 |
|
234 .. code-block:: xml |
|
235 |
|
236 <!-- Mainbuild common sbs options --> |
|
237 <hlm:sbsoptions id="armv5CommonSBS"> |
|
238 <argset refid="commonSBS" /> |
|
239 <arg line="-c armv5" /> |
|
240 </hlm:sbsoptions> |
|
241 |
|
242 |
|
243 could be redefined as below in the user configuration, |
|
244 |
|
245 .. code-block:: xml |
|
246 |
|
247 <!-- Mainbuild common sbs options --> |
|
248 <hlm:sbsoptions id="armv5CommonSBS"> |
|
249 <argset refid="commonSBS" /> |
|
250 <arg line="-c armv5" /> |
|
251 <arg line="-d" /> |
|
252 </hlm:sbsoptions> |
|
253 |
|
254 This would add the debug flag in all the raptor configuration which is using armv5CommonSBS. |