4 .\" " Common Development and Distribution License, Version 1.0 only
5 .\" " (the "License"). You may not use this file except in compliance
6 .\" " 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 .\" "Copyright 2004 Sun Microsystems, Inc."
22 .\" "All rights reserved"
23 .\" "Use is subject to license terms."
24 .TH WS 1ONBLD "28 January 1992"
25 .SH NAME
26 .I ws
27 \- enable SunOS avocet environments
28 .SH SYNOPSIS
29 .B ws
30 [-e] [workspace_name]
31 .LP
32 .SH DESCRIPTION
33 .IX "Avocet" "ws" "" "\fBws\fP"
34 .LP
35 .I Ws
36 will configure your environment to build the SunOS
37 source base from an
38 .I avocet
39 workspace. The
40 .I ws
41 script sets up the environment variables for a SunOS avocet
42 workspace and spawns a shell for the environment
43 that has been setup. In configuring the environment
44 .I ws
45 sets up the environment variables to define in which proto areas
46 you will build against as well as the proto area the will be your
47 install target.
48 .LP
49 The following Environment variables are set when you invoke this script:
50 .LP
51 .RS 5
52 .nf
53 CODEMGR_WS
86 will also check for the presense of the ONBLD construction set
87 (/opt/onbld), if it is found it will prepend the
88 ONBLD construction set directory to the front of your PATH.
89 If you set your path in your shell
90 start-up file (eg: .cshrc) then that will undo what what
91 .I ws
92 has done. If you do this in your shell start-up script,
93 conditionally protect
94 .I ws
95 from your modification with something like this:
96 .LP
97 .RS 5
98 .nf
99 if ( ! $?ONBLD_DIR ) then
100 set path=( ~/bin $path ) # or however you wish to modify path
101 endif
102 .fi
103 .RE
104 .LP
105 NOTE: this is a csh example, the code would vary with the shell type.
106 .LP
107 .SH OPTIONS
108 .LP
109 .TP
110 .B \-e
111 prevent ws from calling exit or exec, useful for setting environment in
112 another Bourne (sh) compatible shell (hint: source ws -e)
113 .LP
114 .SH USAGE
115 .LP
116 At start-up time
117 .I ws
118 will determine the number of proto areas to
119 be searched and in what order. This information is configured
120 during the first invocation of
121 .I ws
122 for each workspace in the protodefs
123 file. This file is located under the avocet directory
124 in your workspace:
125 .LP
126 .RS 5
127 .nf
128 $CODEMGR_WS/avocet/sunos/protodefs
129 .fi
130 .RE
131 .LP
132 In this file you may configure from one to four proto
133 variables (PROTO1, PROTO2, PROTO3, TERMPROTO).
174 The default values for PROTO1 and PROTO2 will be set by
175 .I ws
176 initially to point to your current workspaces proto area and
177 the proto area
178 of the workspace's parent, if the parent is an Avocet
179 workspace.
180 .LP
181 The PROTO{1-3} variables will then be used to set your ROOT variable and
182 to set the ENVCPPFLAGS{1-4} and the ENVDLLIBS{1-3} environment variables.
183 These will be set to an architecture specific directory under
184 each PROTO* directory. If, for example, PROTO1 had been set
185 to PROTO1=/ws/train/proto then ROOT would be set to
186 ROOT=/ws/train/proto/root_${MACH}. MACH would be equal to the
187 architecture of the machine you are running on (ie: `uname -p`).
188 .LP
189 The exception to this is if there is already an existing non-architecture
190 specific populated proto area
191 under one of the PROTO{1-3} variables. If this is the case then the
192 ROOT and other flags will be based on that instead of an architecture
193 specific sub-directory.
194 .LP
195 .SH ISSUES
196 .LP
197 The use of Constrained Files is very different between an NSE
198 environment and an avocet workspace. Constrained files are files which
199 are derived but files that you do not have source code for. For
200 example in an NSE environment, a library would be a constrained file if
201 you acquired a command that depended on that library but you did not
202 acquire the library's sources. If a user is used to working in an NSE
203 environment they should be aware of the differences.
204 .LP
205 In an NSE environment the user was isolated from updates to both
206 constrained files and source files
207 alike in the parent environment. You did not see updates
208 to constrained files until you
209 .I resynced
210 a command or object which depended on the
211 constrained file in question.
212 This is no longer the case under Avocet.
213 .LP
214 If you are using
220 in it's proto area and you are referencing the parents
221 proto area via ws, then
222 that update is immediately visible to you. The next time you
223 build a new command in your avocet workspace you will be building
224 against the new copy of the constrained file(libc.so) which you
225 obtain from your parents proto area, you are no longer isolated from
226 these updates as you were in the NSE.
227 .LP
228 If you would like to be isolated from updates in the
229 world around you there are a couple of approaches you can take. First,
230 if you bringover a full copy of the SunOS source base you could
231 build your own PROTO area which you would link against.
232 Secondly, you could link against a private
233 PROTO area which is a stable snapshot of a global proto area.
234 This proto area could be a subset
235 of a full proto area and contain only those files which you are concerned
236 about. Both of these methods would protect you from updates to files
237 because you would be in full control of the proto areas you are linking
238 against. It would be your responsiblity to update your proto area
239 as your work progressed.
240 .LP
241 .SH EXAMPLES
242 .LP
243 In the following examples you will modify the
244 ${CODEMGR_WS}/avocet/sunos/protodefs file to define PROTO{1-3}
245 to configure a proto hierarchy to be associated with your
246 avocet workspace. I have selected the four
247 most common examples that will be used with avocet workspaces,
248 there can be many other combinations.
249 .LP
250 In the first example we will
251 configure a workspace named
252 caltrans:/bld/child,
253 and it is a child of an avocet workspace named dunk:/build/parent. The
254 parent workspace (dunk:/build/parent)
255 is a complete copy of the usr/src source tree, while the
256 current workspace(caltrans:/bld/child) is a subset of the full
257 source base. The current(child) workspace only contains the usr/src/cmd
258 directories. The proto areas that
259 we want to search are the current workspaces proto area(/bld/child/proto)
260 and then the proto area of the parent(/net/dunk/build/parent/proto), in that
334 Lastly, we have an avocet workspace named
335 caltrans:/bld/nse_child which is the child of an NSE environment.
336 Because the parent of the workspace is an NSE environment, that parent
337 does not have a PROTO area associated with it that we can
338 refer to. Instead there is a global PROTO area that is maintained
339 by our 'I-Team' leader that we will refer to. That global area
340 is located at rainman:/space/I-team-protoarea. Here is what
341 the protodefs file would look like:
342 .LP
343 .RS 5
344 .nf
345 PROTO1=/bld/nse_child
346 PROTO2=/net/rainman/space/I-team-protoarea
347 .fi
348 .RE
349 .LP
350 This model differs from the one above in that we can not reference
351 the parents proto area because the parent in an NSE environment.
352 Instead for our second proto area we point to a stable proto
353 area outside of the NSE.
354 .LP
355 .SH ENVIRONMENT VARIABLES
356 .LP
357 Here is a list of the environment variables that
358 .I ws
359 will set and how they are used:
360 .LP
361 CODEMGR_WS
362 .fi
363 .RS 5
364 Absolute pathname to the Avocet workspace. This environment variable
365 is referenced by the
366 .I bringover
367 ,
368 .I putback
369 ,
370 and
371 .I workspace
372 commands.
373 .RE
374 SRC
375 .RS 5
376 Root of SunOS source code, referenced by SunOS Makefiles.
377 .RE
378 ROOT
379 .RS 5
380 Initial proto area for this workspace. Again this is used by the
381 SunOS Makefiles. This value is set based on PROTO1 as defined in
382 the protodefs file. ROOT is also the destination of
396 .RE
397 MAKEFLAGS
398 .RS 5
399 Default MAKEFLAGS used by
400 .I make,
401 set to 'e' for higher environment precedence.
402 .RE
403 ENVCPPFLAGS{1-4}
404 .RS 5
405 This set of environment variables is used to set the
406 CPPFLAGS.master macro within the SunOS source tree. These values
407 usually point to a hierarchy of Include directories for the build
408 to search through.
409 .RE
410 ENVLDLIBS{1-3}
411 .RS 5
412 This set of environment variables is used to set the LDLIBS.master
413 macro within the SunOS source tree. These values usually point
414 to a hierarchy of directories to search for libraries.
415 .RE
416 .LP
417 .SH FILES
418 .LP
419 .nf
420 $CODEMGR_WS/avocet/sunos/protodefs
421 .fi
422 .LP
423 .SH "SEE ALSO"
424 .LP
425 .IR workspace (1),
426 .IR bringover (1ONBLD),
427 .IR putback (1),
428 .IR protodefs(5)
429 .LP
430 .SH BUGS
431 .LP
432 TERMPROTO is broken.
433 On 5.x builds TERMPROTO is incompatible with the C++ driver. The bug
434 is that the C++ driver does not use the standard SVR4 notation
435 for the -Y I, option.
436 .LP
437 .I ws
438 can have problems with the automounter. If you refer to a workspace
439 using a relative path, and that workspace is mounted via the automounter,
440 then that workspace will be refered to via the /tmp_mnt/*
441 location. It's best to deal with automounted workspaces through
442 an absolute pathname when running
443 .I ws.
|
4 .\" " Common Development and Distribution License, Version 1.0 only
5 .\" " (the "License"). You may not use this file except in compliance
6 .\" " 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 .\" "Copyright 2004 Sun Microsystems, Inc."
22 .\" "All rights reserved"
23 .\" "Use is subject to license terms."
24 .TH WS 1ONBLD "Jan 28, 1992"
25 .SH NAME
26 .I ws
27 \- enable SunOS avocet environments
28 .SH SYNOPSIS
29 .B ws
30 [-e] [workspace_name]
31 .SH DESCRIPTION
32 .LP
33 .I Ws
34 will configure your environment to build the SunOS
35 source base from an
36 .I avocet
37 workspace. The
38 .I ws
39 script sets up the environment variables for a SunOS avocet
40 workspace and spawns a shell for the environment
41 that has been setup. In configuring the environment
42 .I ws
43 sets up the environment variables to define in which proto areas
44 you will build against as well as the proto area the will be your
45 install target.
46 .LP
47 The following Environment variables are set when you invoke this script:
48 .LP
49 .RS 5
50 .nf
51 CODEMGR_WS
84 will also check for the presense of the ONBLD construction set
85 (/opt/onbld), if it is found it will prepend the
86 ONBLD construction set directory to the front of your PATH.
87 If you set your path in your shell
88 start-up file (eg: .cshrc) then that will undo what what
89 .I ws
90 has done. If you do this in your shell start-up script,
91 conditionally protect
92 .I ws
93 from your modification with something like this:
94 .LP
95 .RS 5
96 .nf
97 if ( ! $?ONBLD_DIR ) then
98 set path=( ~/bin $path ) # or however you wish to modify path
99 endif
100 .fi
101 .RE
102 .LP
103 NOTE: this is a csh example, the code would vary with the shell type.
104 .SH OPTIONS
105 .TP
106 .B \-e
107 prevent ws from calling exit or exec, useful for setting environment in
108 another Bourne (sh) compatible shell (hint: source ws -e)
109 .SH USAGE
110 .LP
111 At start-up time
112 .I ws
113 will determine the number of proto areas to
114 be searched and in what order. This information is configured
115 during the first invocation of
116 .I ws
117 for each workspace in the protodefs
118 file. This file is located under the avocet directory
119 in your workspace:
120 .LP
121 .RS 5
122 .nf
123 $CODEMGR_WS/avocet/sunos/protodefs
124 .fi
125 .RE
126 .LP
127 In this file you may configure from one to four proto
128 variables (PROTO1, PROTO2, PROTO3, TERMPROTO).
169 The default values for PROTO1 and PROTO2 will be set by
170 .I ws
171 initially to point to your current workspaces proto area and
172 the proto area
173 of the workspace's parent, if the parent is an Avocet
174 workspace.
175 .LP
176 The PROTO{1-3} variables will then be used to set your ROOT variable and
177 to set the ENVCPPFLAGS{1-4} and the ENVDLLIBS{1-3} environment variables.
178 These will be set to an architecture specific directory under
179 each PROTO* directory. If, for example, PROTO1 had been set
180 to PROTO1=/ws/train/proto then ROOT would be set to
181 ROOT=/ws/train/proto/root_${MACH}. MACH would be equal to the
182 architecture of the machine you are running on (ie: `uname -p`).
183 .LP
184 The exception to this is if there is already an existing non-architecture
185 specific populated proto area
186 under one of the PROTO{1-3} variables. If this is the case then the
187 ROOT and other flags will be based on that instead of an architecture
188 specific sub-directory.
189 .SH ISSUES
190 .LP
191 The use of Constrained Files is very different between an NSE
192 environment and an avocet workspace. Constrained files are files which
193 are derived but files that you do not have source code for. For
194 example in an NSE environment, a library would be a constrained file if
195 you acquired a command that depended on that library but you did not
196 acquire the library's sources. If a user is used to working in an NSE
197 environment they should be aware of the differences.
198 .LP
199 In an NSE environment the user was isolated from updates to both
200 constrained files and source files
201 alike in the parent environment. You did not see updates
202 to constrained files until you
203 .I resynced
204 a command or object which depended on the
205 constrained file in question.
206 This is no longer the case under Avocet.
207 .LP
208 If you are using
214 in it's proto area and you are referencing the parents
215 proto area via ws, then
216 that update is immediately visible to you. The next time you
217 build a new command in your avocet workspace you will be building
218 against the new copy of the constrained file(libc.so) which you
219 obtain from your parents proto area, you are no longer isolated from
220 these updates as you were in the NSE.
221 .LP
222 If you would like to be isolated from updates in the
223 world around you there are a couple of approaches you can take. First,
224 if you bringover a full copy of the SunOS source base you could
225 build your own PROTO area which you would link against.
226 Secondly, you could link against a private
227 PROTO area which is a stable snapshot of a global proto area.
228 This proto area could be a subset
229 of a full proto area and contain only those files which you are concerned
230 about. Both of these methods would protect you from updates to files
231 because you would be in full control of the proto areas you are linking
232 against. It would be your responsiblity to update your proto area
233 as your work progressed.
234 .SH EXAMPLES
235 .LP
236 In the following examples you will modify the
237 ${CODEMGR_WS}/avocet/sunos/protodefs file to define PROTO{1-3}
238 to configure a proto hierarchy to be associated with your
239 avocet workspace. I have selected the four
240 most common examples that will be used with avocet workspaces,
241 there can be many other combinations.
242 .LP
243 In the first example we will
244 configure a workspace named
245 caltrans:/bld/child,
246 and it is a child of an avocet workspace named dunk:/build/parent. The
247 parent workspace (dunk:/build/parent)
248 is a complete copy of the usr/src source tree, while the
249 current workspace(caltrans:/bld/child) is a subset of the full
250 source base. The current(child) workspace only contains the usr/src/cmd
251 directories. The proto areas that
252 we want to search are the current workspaces proto area(/bld/child/proto)
253 and then the proto area of the parent(/net/dunk/build/parent/proto), in that
327 Lastly, we have an avocet workspace named
328 caltrans:/bld/nse_child which is the child of an NSE environment.
329 Because the parent of the workspace is an NSE environment, that parent
330 does not have a PROTO area associated with it that we can
331 refer to. Instead there is a global PROTO area that is maintained
332 by our 'I-Team' leader that we will refer to. That global area
333 is located at rainman:/space/I-team-protoarea. Here is what
334 the protodefs file would look like:
335 .LP
336 .RS 5
337 .nf
338 PROTO1=/bld/nse_child
339 PROTO2=/net/rainman/space/I-team-protoarea
340 .fi
341 .RE
342 .LP
343 This model differs from the one above in that we can not reference
344 the parents proto area because the parent in an NSE environment.
345 Instead for our second proto area we point to a stable proto
346 area outside of the NSE.
347 .SH ENVIRONMENT VARIABLES
348 .LP
349 Here is a list of the environment variables that
350 .I ws
351 will set and how they are used:
352 .LP
353 CODEMGR_WS
354 .RS 5
355 Absolute pathname to the Avocet workspace. This environment variable
356 is referenced by the
357 .I bringover
358 ,
359 .I putback
360 ,
361 and
362 .I workspace
363 commands.
364 .RE
365 SRC
366 .RS 5
367 Root of SunOS source code, referenced by SunOS Makefiles.
368 .RE
369 ROOT
370 .RS 5
371 Initial proto area for this workspace. Again this is used by the
372 SunOS Makefiles. This value is set based on PROTO1 as defined in
373 the protodefs file. ROOT is also the destination of
387 .RE
388 MAKEFLAGS
389 .RS 5
390 Default MAKEFLAGS used by
391 .I make,
392 set to 'e' for higher environment precedence.
393 .RE
394 ENVCPPFLAGS{1-4}
395 .RS 5
396 This set of environment variables is used to set the
397 CPPFLAGS.master macro within the SunOS source tree. These values
398 usually point to a hierarchy of Include directories for the build
399 to search through.
400 .RE
401 ENVLDLIBS{1-3}
402 .RS 5
403 This set of environment variables is used to set the LDLIBS.master
404 macro within the SunOS source tree. These values usually point
405 to a hierarchy of directories to search for libraries.
406 .RE
407 .SH FILES
408 .LP
409 .nf
410 $CODEMGR_WS/avocet/sunos/protodefs
411 .fi
412 .SH "SEE ALSO"
413 .LP
414 .IR workspace (1),
415 .IR bringover (1ONBLD),
416 .IR putback (1),
417 .IR protodefs(5)
418 .SH BUGS
419 .LP
420 TERMPROTO is broken.
421 On 5.x builds TERMPROTO is incompatible with the C++ driver. The bug
422 is that the C++ driver does not use the standard SVR4 notation
423 for the -Y I, option.
424 .LP
425 .I ws
426 can have problems with the automounter. If you refer to a workspace
427 using a relative path, and that workspace is mounted via the automounter,
428 then that workspace will be refered to via the /tmp_mnt/*
429 location. It's best to deal with automounted workspaces through
430 an absolute pathname when running
431 .I ws.
|