1 #
2 # CDDL HEADER START
3 #
4 # The contents of this file are subject to the terms of the
5 # Common Development and Distribution License (the "License").
6 # You may not use this file except in compliance with the License.
7 #
8 # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9 # or http://www.opensolaris.org/os/licensing.
10 # See the License for the specific language governing permissions
11 # and limitations under the License.
12 #
13 # When distributing Covered Code, include this CDDL HEADER in each
14 # file and include the License file at usr/src/OPENSOLARIS.LICENSE.
15 # If applicable, add the following below this CDDL HEADER, with the
16 # fields enclosed by brackets "[]" replaced with your own identifying
17 # information: Portions Copyright [yyyy] [name of copyright owner]
18 #
19 # CDDL HEADER END
20 #
21 #
22 # Copyright (c) 1999, 2010, Oracle and/or its affiliates. All rights reserved.
23
24
25 This directory contains the tools used to do a full build of the
26 OS/Net workspace. They usually live in the /opt/onbld directory on build
27 machines. From here, 'make install' will build and install the tools
28 in $ROOT/opt/onbld.
29
30 Layout of /opt/onbld
31 --------------------
32
33 /opt/onbld/etc/abi
34 contains Solaris ABI database (ABI_*.db) and exceptions
35 for ABI Auditing tool (interface_check, interface_cmp).
36
37 /opt/onbld/bin
38 basic bin directory - contains scripts.
39
40 /opt/onbld/bin/${MACH}
41 architecture-specific bin directory for binaries.
42
43 /opt/onbld/env
44 build environment files.
45
46 /opt/onbld/lib
47 libraries used by the build tools.
48
49 /opt/onbld/lib/python<version>/
50 python modules used by the build tools.
51
52 /opt/onbld/lib/python/
53 symlink to the modules directory of the currently preferred
54 python version.
55
56 /opt/onbld/man
57 rudimentary man pages for some of the tools.
58
59
60 Tool Summary
61 ------------
62
63 bldenv
64 companion to 'nightly.' Takes the same environment file you
65 used with 'nightly,' and starts a shell with the environment
66 set up the same way as 'nightly' set it up. This is useful
67 if you're trying to quickly rebuild portions of a workspace
68 built by 'nightly'. 'ws' should not be used for this since it
69 sets the environment up differently and may cause everything
70 to rebuild (because of different -I or -L paths).
71
72 build_cscope
73 builds cscope databases in the uts, the platform subdirectories
74 of uts, and in usr/src. Uses cscope-fast.
75
76 check_rtime
77 checks ELF attributes used by ELF dynamic objects in the proto area.
78 Used by 'nightly's -r option, to check a number of ELF runtime
79 attributes for consistency with common build rules. nightly uses
80 the -o option to simplify the output for diffing with previous
81 build results. It also uses the -i option to obtain NEEDED and RUNPATH
82 entries, which help detect changes in software dependencies and makes
83 sure objects don't have any strange runpaths like /opt/SUNWspro/lib.
84
85 codereview
86 Given two filenames, creates a postscript file with the file
87 differences highlighted.
88
89 codesign
90 Tools for signing cryptographic modules using the official
91 Sun release keys stored on a remote signing server. This
92 directory contains signit, a client program for signing
93 files with the signing server; signproto, a shell script
94 that finds crypto modules in $ROOT and signs them using
95 signit; and codesign_server.pl, the code that runs on the
96 server. The codesign_server code is not used on an ON
97 build machine but is kept here for source control purposes.
98
99 copyrightchk
100 Checks that files have appropriate SMI copyright notices.
101 Primarily used by wx
102
103 cscope-fast
104 The fast version of cscope that we use internally. Seems to work,
105 but may need more testing before it's placed in the gate. The source
106 just really needs to be here.
107
108 cstyle
109 checks C source for compliance with OS/Net guidelines.
110
111 ctfconvert
112 Convert symbolic debugging information in an object file to the Compact
113 ANSI-C Type Format (CTF).
114
115 ctfdump
116 Decode and display CTF data stored in a raw file or in an ELF file.
117
118 ctfmerge
119 Merge the CTF data from one or more object files.
120
121 elfcmp
122 Compares two ELF modules (e.g. .o files, executables) section by
123 section. Useful for determining whether "trivial" changes -
124 cstyle, lint, etc - actually changed the code. The -S option
125 is used to test whether two binaries are the same except for
126 the elfsign signature.
127
128 find_elf
129 Search a directory tree for ELF objects, and produce one line of
130 output per object. Used by check_rtime and interface_check to locate
131 the objects to examine.
132
133 findunref
134 Finds all files in a source tree that have access times older than a
135 certain time and are not in a specified list of exceptions. Since
136 'nightly' timestamps the start of the build, and findunref uses its
137 timestamp (by default), this can be used to find all files that were
138 unreferenced during a nightly build). Since some files are only used
139 during a SPARC or Intel build, 'findunref' needs to be run on
140 workspaces from both architectures and the results need to be merged.
141 For instance, if $INTELSRC and $SPARCSRC are set to the usr/src
142 directories of your Intel and SPARC nightly workspaces, then you
143 can merge the results like so:
144
145 $ findunref $INTELSRC $INTELSRC/tools/findunref/exception_list | \
146 sort > ~/unref-i386.out
147 $ findunref $SPARCSRC $SPARCSRC/tools/findunref/exception_list | \
148 sort > ~/unref-sparc.out
149 $ comm -12 ~/unref-i386.out ~/unref-sparc.out > ~/unref.out
150
151 hdrchk
152 checks headers for compliance with OS/Net standards (form, includes,
153 C++ guards).
154
155 install.bin
156 binary version of /usr/sbin/install. Used to be vastly faster
157 (since /usr/sbin/install is a shell script), but may only be a bit
158 faster now. One speedup includes avoiding the name service for the
159 well-known, never-changing password entries like 'root' and 'sys.'
160
161 interface_check
162 detects and reports invalid versioning in ELF objects.
163 Optionally generates an interface description file for
164 the workspace.
165
166 interface_cmp
167 Compares two interface description files, as produced by
168 interface_check, and flags invalid deviations in ELF object
169 versioning between them. interface_cmp can be used between Solaris
170 gates to ensure that older releases remain compatible with the
171 development gate. It can also be used to validate new changes to
172 the development gate before they are integrated.
173
174 lintdump
175 dumps the contents of one or more lint libraries; see lintdump(1)
176
177 ndrgen
178 Network Data Language (NDL) RPC protocol compiler to support DCE
179 RPC/MSRPC and SMB/CIFS. ndrgen takes an input protocol definition
180 file (say, proto.ndl) and generates an output C source file
181 (proto_ndr.c) containing the Network Data Representation (NDR)
182 marshalling routines to implement the RPC protocol.
183
184 nightly
185 nightly build script. Takes an environment (or 'env') file describing
186 such things as the workspace, the parent, and what to build. See
187 env/developer and env/gatekeeper for sample, hopefully well-commented
188 env files.
189
190 protocmp
191 compares proto lists and the package definitions. Used by nightly
192 to determine if the proto area matches the packages, and to detect
193 differences between a childs proto area and a parents.
194
195 protocmp.terse
196 transforms the output of protocmp into something a bit more friendly
197
198 protolist
199 create a list of what's in the proto area, to feed to protocmp.
200
201
202 ws
203 creates a shell with the environment set up to build in the given
204 workspace. Used mostly for non-full-build workspaces, so it sets up
205 to pull headers and libraries from the proto area of the parent if
206 they aren't in the childs proto area.
207
208 tokenize
209 Used to build the sun4u boot block.
210
211 webrev
212 Generates a set of HTML pages that show side-by-side diffs of
213 changes in your workspace, for easy communication of code
214 review materials. Can automagically find edited files or use a
215 manually-generated list; knows how to use wx's active file for
216 lists of checked-out files and proposed SCCS comments.
217
218 which_scm
219 Reports the current Source Code Management (SCM) system in use
220 and the top-level directory of the workspace.
221
222 wsdiff
223 Detect object differences between two ON proto areas. Used by
224 nightly(1) to determine what changed between two builds. Handy
225 for identifying the set of built objects impacted by a given
226 source change. This information is needed for patch construction.
227
228
229 How to do a full build
230 ----------------------
231
232 1. Find an environment file that might do what you want to do. If you're just
233 a developer wanting to do a full build in a child of the gate, copy the
234 'developer' environment file to a new name (private to you and/or the
235 work being done in this workspace, to avoid collisions with others). Then
236 edit the file and tailor it to your workspace. Remember that this file
237 is a shell script, so it can do more than set environment variables.
238
239 2. Run 'nightly' and give it your environment file as an
240 option. 'nightly' will first look for your environment file in
241 /opt/onbld/env, and if it's not there then it will look for it as an
242 absolute or relative path. Some people put their environment files in
243 their workspace to keep them close.
244
245 3. When 'nightly' is complete, it will send a summary of what happened to
246 $MAILTO. Usually, the less info in the mail the better. If you have failures,
247 you can go look at the full log of what happened, generally in
248 $CODEMGR_WS/log/log.<date>/nightly.log (the mail_msg it sent and the proto
249 list are there too). You can also find the individual build logs, like
250 'make clobber' and 'make install' output in $SRC, under names like
251 clobber-${MACH}.out and install-${MACH}.out (for a DEBUG build). These
252 will be smaller than nightly.log, and maybe more searchable.
253
254 Files you have to update to add a tool
255 --------------------------------------
256
257 1. Add the tool in its appropriate place.
258 2. Update the Makefile as required.
259 3. Update usr/src/pkg/manifests/developer-build-onbld.mf
260 4. Update usr/src/tools/README.tools (this file).
261 5. Repeat 1-4 for any man pages.