1 Workshop Organisation Kit {#occt_dev_guides__wok}
2 =========================
6 @section occt_wok_0 DEPRECATION WARNING
8 Please note that this document describes use of WOK as comprehensive
9 build system. This use is outdated, and WOK is to be removed in
10 one of future releases of OCCT.
12 Currently only small subset of WOK capabilities described in this document
13 are actually necessary for building OCCT. See @ref occt_dev_guides__building_wok
14 for more practical guide.
16 @section occt_wok_1_ Introduction Glossary
18 @subsection occt_wok_1_1 About the Development Environment
20 Open CASCADE Technology (**OCCT**) development environment is able to accommodate large numbers of developers working on a variety of products. Within this environment developers can produce multiple versions of products for various hardware and software platforms, including versions corresponding to particular marketing requirements. At the same time, OCCT development environment enables the maximum possible reuse of software components. In other words, OCCT development environment is designed to facilitate industrial scale development.
21 @subsection occt_wok_1_2 Brief Overview of Open CASCADE Technology Development Environment
22 The following diagram shows OPEN CASCADE tools and resources, the development method, and the architecture of applications that you can develop with Open CASCADE Technology.
24 @image html /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
25 @image latex /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
27 The application developer goes about creating his application by editing his source code and producing the final application using a set of intelligent construction tools. These tools are available within a structured development environment called the **software factory**.
29 The developer defines new software components in CDL, Component Description Language, and uses a CDL compiler to derive their C++ implementations. These components are then compiled into packages.
30 @subsection occt_wok_1_3 WOK Components
31 @subsubsection occt_wok_1_3_1 Entities
32 The WOK environment is made up of entities, for example software factories and development units. A full list of WOK entities is provided in the <a href="#occt_wok_1_4">Glossary</a> section.
33 @subsubsection occt_wok_1_3_2 Files
34 WOK manages two different types of files: user source files and WOK administration files. To support this, each entity has a home directory, which contains its administration directory. This is called *adm* and stores the administration files that WOK needs. In addition development units have a source directory called *src*, which contains both .cdl and .cxx source files, and a header file directory called *inc*, which contains .hxx files.
36 @subsection occt_wok_1_4 Glossary
37 @subsubsection occt_wok_1_4_1 Development Units
38 A **development unit** is the smallest unit that can be subject to basic development operations such as modifying, compiling, linking and building.
39 The following list contains all types of development units. The letter in parentheses indicates the letter key by commands such as *ucreate* and *umake*. In the rest of the manual, this letter key is referred to as the *short key*.
40 * package (p) A set of related classes and methods along with their CDL definitions.
41 * schema (s) A set of persistent data types.
42 * executable (x) An executable is used for unit and integration test purposes. It is based on one or more packages.
43 * nocdlpack (n) A package without a CDL definition. Used for low-level programming or for incorporating foreign resources.
44 * interface (i) A specific set of services available for wrapping (an interface contains packages, classes, and methods).
45 * jni (j) A development unit used to wrap C++ classes to Java. It is based on one or more interfaces.
46 * toolkit (t) A set of packages. Useful in grouping packages together when there is a large number of packages based around a particular subject.
47 * delivery (d) A development unit for publishing development units.
48 * resource (r) A development unit containing miscellaneous files.
50 @subsubsection occt_wok_1_4_2 Workbenches
51 A workbench is a specialized directory structure where the user creates, modifies, and uses development units. A workbench is likely to be the personal property of one user or at most a small team of developers.
52 @image html /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
53 @image latex /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
55 @subsubsection occt_wok_1_4_3 Workshops
56 A workshop is a tree of workbenches. It provides the development team with an independent workspace inside which the complete cycle of software production can be carried out.
57 The root workbench is in a valid state and contains the working versions of the development units.
58 Development units in a root workbench are visible in its child workbenches.
60 For example, the schema below shows a workshop containing three workbenches. Workbenches B and C are the children of workbench A. Development units in A are visible in both B and C
61 @image html /dev_guides/wok/images/wok_image007.png "Workbenches"
62 @image latex /dev_guides/wok/images/wok_image007.png "Workbenches"
64 Workshops are fully independent of each other. They are organized in such a way that development units can be grouped into a delivery and placed in a warehouse. Communication between workshops is carried out by means of these deliveries. A warehouse belongs to a factory and is visible from all workshops in that factory. In this way, development units can be shared between a group of development teams.
66 @image html /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
67 @image latex /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
69 @subsubsection occt_wok_1_4_4 Factories
70 A factory is a set of workshops and their corresponding warehouse. There is a single warehouse in any factory. The continuous upgrading and improvement of a product is carried out in a specific factory.
71 To create a new version of an application within the factory, you establish a new workshop dedicated to creation and support of the new version.
73 @image html /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
74 @image latex /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
76 @section occt_wok_2_ Elements of the Platform
77 @subsection occt_wok_2_1 Development Units
78 A **development unit** is the basic element of WOK development. It includes the following three entities:
79 * A directory structure (a minor component)
80 * Source files, also called primary files
81 * The result of the build process (compilation, etc.), also called derived files.
83 @subsubsection occt_wok_2_1_1 Directory Structure of a Development Unit
84 The directory structure of a development unit consists of a tree of directories, which are created when the development unit is initialized. Refer to the <a href="#occt_wok_2_2">Workbenches</a> section for further details on the workbench structure.
85 @subsubsection occt_wok_2_1_2 Files in a Development Unit
89 Source files are written by the developer in the source section (the *src* directory) of the development unit.
90 Each development unit maintains the description of its own source files, and this description is stored in one or more files within the *src* directory. The details of how the description is stored vary according to development unit type as shown below:
91 * package (p) The names of all source files are worked out from the CDL description, following the conventions described in the *C++ Programming Guide*. This list of files can be supplemented by additional files listed in the file called FILES. This file must be stored in the unit’s src directory. Whenever header files are included in the *src* directory of a development unit, they must be specified in FILES so that the C++ preprocessor will take them into account. This reduces compilation time by 10 to 40 percent.
92 * schema (s) No description of the source files is needed. There is a single source file: *schema.cdl*.
93 * executable (x) The names of all source files are worked out from the CDL description. The format of this file is described in the <a href="#occt_wok_3_5">Building an Executable</a> section.
94 * nocdlpack (n) The list of source files is contained in the FILES file stored in the unit’s src directory.
95 interface (i). No description of the source files is needed. There is a single source file: *interface.cdl*.
96 * jni (j). No description of the source files is needed. There is a single source file: *jni.cdl*.
97 * toolkit (t) The description is given by the file called PACKAGES which is stored in the unit’s src directory. FILES must also exist in this directory, and must include PACKAGES in its list of files.
98 * delivery (d) The description is given by two files stored in the unit’s src directory: FILES and a file called COMPONENTS. FILES must include COMPONENTS in its list of files.
99 * resource (r) A resource unit is used in a delivery. FILES contains a list of the unit’s files, one per line in the following format: *atype\:\:\:afilename* Here, *filename* is the name of a file, which the compiler will look for in the src directory of the unit, and *atype* is a WOK type. To display a list of all available WOK types, use the command: *wokinfo -T*.
103 Derived files created by compilation are automatically placed in the derived section of the development unit. These may be executable files or archives of compilation results.
105 @subsubsection occt_wok_2_1_3 Package
107 A package is a development unit that defines a set of classes, which share a number of common features such as similar data structure or a set of complementary algorithmic services. Packages help to manage creation and the use of large hierarchies of software components.
108 To create a package, you write a .cdl file describing it in the src directory of the package development unit. The description includes classes and global methods, which comprise it. Each class is also described in a separate .cdl file. The package .cdl file also lists the packages used in the specification of its classes and methods.
109 C++ implementation files are also stored in the src subdirectory of the package development unit. These implementation files are:
110 * .cxx for an ordinary class
111 * .lxx for any inline methods
112 * .pxx for any private declarations
113 * .gxx for a generic class
115 To create the Development Unit structure for a package use the following syntax:
120 The package description has the following CDL syntax:
123 [uses AnotherPackage {‘,’ YetAnotherPackage}]
141 deferred class Element;
144 class LocalReference;
145 Adjust(awheel: wheel from CycleModel;
146 aframe: Frame from CycleModel);
149 For full details on the CDL syntax, refer to the *CDL User’s Guide*.
151 @subsubsection occt_wok_2_1_4 Schema
153 A schema is a development unit that defines the set of all data types, which your application is likely to need in order to read and write files. Such data types are **persistent**.
155 To create a schema, write a .cdl file that lists all the packages, which contain all persistent data types used by the application. Note that only persistent classes are taken into account during compilation; transient classes are ignored.
157 Note that you don’t have to put dependencies in all packages and classes. You only have to write the highest level dependencies. In other words, the *uses* keyword in the schema file allows you to list packages. Any package similarly listed in the package files for these packages are also incorporated into the schema.
159 To create the Development Unit structure for a schema use the syntax below:
164 The schema description has the following CDL syntax :
169 ListOfPackagesContainingPersistentClasses;
170 ListOfPersistentClasses;
178 class Wheel from package CycleModel;
179 class Frame from package CycleModel;
181 class Spanner from package CycleTools;
184 For full details on the CDL syntax, refer to the *CDL User’s Guide*.
186 @subsubsection occt_wok_2_1_5 Executable
187 The purpose of an executable is to make executable programs. The executable can use services from one or more packages and is described in a .cdl file as a set of packages.
189 To create an executable, you write one or more MyExe.cxx files in the src subdirectory of the unit. This file will contain the main function. Then it is possible to compile the executable.
191 To create the Development Unit structure for an executable, use the syntax below:
196 The executable description has the following CDL syntax:
200 executable BinaryFile
211 executable MyExecUnit’
225 For full details on the CDL syntax, refer to the *CDL Reference Manual*.
227 @subsubsection occt_wok_2_1_6 Toolkit
228 A toolkit is a development unit that groups a set of packages to create a shareable library. An example of a toolkit is the ModelingData module. Toolkits serve for the following purposes:
229 * Linking of large numbers of packages
230 * Faster loading of executable files that use toolkits such as test files.
232 A toolkit has no CDL definition. Creating a toolkit involves writing a PACKAGES file in the src subdirectory of its development unit. This file lists all the packages needed in the toolkit. You then create a definition of this file to the FILES.
234 You then compile the toolkit to create a shareable library.
236 @subsubsection occt_wok_2_1_7 Nocdlpack
237 A nocdlpack is a development unit that has no CDL definition. It is compiled directly from source files written in C, C++, Fortran, or in sources to be treated by the lex or yacc tools. A nocdlpack is useful when you write a low-level interface with another product, for example, a network application.
239 To define a nocdlpack, you create a file called FILES in the src subdirectory of the nocdlpack development unit. In this file, you list the Fortran, C, C++, lex, and yacc files that compose the pack. You list the files one per line.
241 On compilation, the result is a shareable library.
243 @subsubsection occt_wok_2_1_8 Interface
244 An interface is a development unit that defines a set of services available for wrapping into Java.
245 An interface is defined in a .cdl file as a list of packages, package methods, classes, and methods. It makes these available to a jni unit.
247 To create the Development Unit structure for an interface, use the syntax below:
249 ucreate -i MyInterface
252 The interface description has the following CDL syntax:
255 interface InterfaceName
265 interface MyInterface
268 class Shape from ShapeFix;
272 @subsubsection occt_wok_2_1_9 Jni
273 A jni is a development unit that wraps declared services into Java using JNI (Java Native Interface).
275 A jni creates Java classes that are used as C++ counterparts when developing in Java.
277 To create the Development Unit structure for an Jni, use the syntax below:
280 The interface description has the following CDL syntax:
284 {interface InterfaceName;}
292 interface MyInterface;
293 interface MyAnotherInterface;
297 @subsubsection occt_wok_2_1_10 Delivering Parcels
298 The delivery process allows creating parcels. These parcels group together the development work done within a given workshop. You can ship these parcels to other workshops called client workshops.
300 A delivery is autonomous. Once the delivery development unit is compiled, a parcel is stored in the factory warehouse and has no more connection with the workshop where it was created. A parcel has its own directory structure.
302 All Open CASCADE Technology resources are seen as parcels.
304 @image html /dev_guides/wok/images/wok_image010.png "Parcels"
305 @image latex /dev_guides/wok/images/wok_image010.png "Parcels"
307 You create a delivery unit under a specified workbench.
309 You are **strongly advised** to create delivery units under the *root* workbench of the workshop. Child workbenches could be deleted in the future, whereas the root workbench is likely to remain untouched. In other words, you safeguard the delivery by creating it in the root workbench.
311 **Note** If you do not specify a workbench when you make a delivery, it is created under the current workbench.
313 @subsection occt_wok_2_2 Workbenches
314 A workbench is generally the place where one particular developer or a team of developers works on a particular development. A workbench is composed of a public part and a private part.
316 @subsubsection occt_wok_2_2_1 Roots
317 The following roots are used in the structure of a workbench:
318 * **Home** Workbench root containing various administration files of the workbench.
319 * **Src** Root of the workbench sources, which facilitates the integration into WOK of version management software such as CVS.
320 * **DBMS** Root of the derived files dependent on the extraction profile (.hxx, _0.cxx files, etc.).
321 * **DBMS_Station** Roots of the derived files dependent on the extraction profile and on the platform (.o, .so files, etc.).
323 Roots are defined for each profile and platform supported by the workbench. For example, a workbench supporting the DFLT profile on Sun and SGI platforms has the following roots:
324 * **Home** Workbench root,
325 * **Src** Root of the source files,
326 * **DFLT** Root of the derived files,
327 * **DFLT_sun** Root of the files built on Sun platforms,
328 * **DFLT_sil** Root of the files built on SGI platforms,
330 For a workbench additionally supporting *ObjectStore*, the following additional roots are also found: *OBJS, OBJS_sun, OBJS_sil*.
332 These roots are defined in the workbench definition file *MyWorkbench.edl* as the parameter <i>\%MyWorkbench_RootName</i>.
334 **Note** that default values help to define various roots.
336 @subsubsection occt_wok_2_2_2 Directories
337 Under each root, a hierarchy of directories allows to store various files.
338 * Under the Home root are found:
339 * *work*, the private workbench directory reserved for the developer
340 * *Adm*, the directory reserved for administration files.
342 * *src/MyUD*, the directory containing the source files of the development unit MyUD.
344 * *inc*, containing the public header files of the workbench UDs
345 * *drv/MyUD*, containing the private extracted files of MyUD
346 * *drv/MyUD/.adm*, containing the administration files dependent on the extraction profile
347 * *drv/MyUD/.tmp*, containing the temporary files dependent on the extraction profile.
348 * DBMS_Station contains:
349 * *\<station\>/lib* with all the libraries produced in the workbench
350 * *\<station\>/bin* with all the binaries produced in the workbench
351 * *\<station\>/MyUD* with all the station dependent files which are private to the development unit such as objects
352 * *\<station\>/MyUD/.adm* with all the station dependent administration files
353 * *\<station\>/MyUD/.tmp* with all the temporary files constructed in the development unit.
356 @image html /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
357 @image latex /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
359 @subsection occt_wok_2_2_3 Workshops
360 A **workshop** is an independent workspace inside which the complete cycle of software production is carried out. Workbenches inside a workshop are organized so that development units can be shared either by being published in a father workbench or by being placed in reference in the root workbench.
362 @image html /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
363 @image latex /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
366 * **A** is the development unit A from Grandchild 11 placed in reference in root. It is visible throughout the workshop.
367 * **B** is the development unit B from Grandchild 12 published in ancestor Child 1. It is visible to Child 1, Grandchild 11 and Grandchild 12.
370 In a large-scale development that involves one or more teams of developers, you should decide how you are going to structure a workshop right at the beginning. If need be, you can review your decision later.
372 An existing workshop can be duplicated and the original workshop can be used as the basis for maintaining the present version of a product. The new workshop can then be used to develop and maintain a new version of the product.
374 When creating a new workshop, you specify - in the form of parcels – which resources are to be available within the workshop.
376 @subsection occt_wok_2_2_4 Factories
377 A factory contains a number of workshops and a warehouse. When Open CASCADE Technology is installed, the system administrator creates a single factory. This contains a single workshop as well as the warehouse containing OCCT resources in the form of parcels.
379 There is no theoretical limit to the number of workshops that can be added to a factory. However, a single factory should be enough.
381 @section occt_wok_3 Development Process
382 @subsection occt_wok_3_1 WOK Environment
383 The WOK interface is based on tcl, a command language provided by the Regents of the University of California and Sun Microsystems, Inc. The WOK development environment is in fact a tcl session.
386 Before you run a tcl session you must make sure that your account is configured for using tcl, see the <a href="#occt_wok_8_3">Configuring Your Account for Tcl and WOK</a> section.
388 To start a tcl session use the command:
392 Within this session, all WOK commands are available as well as standard tcl commands. You can also use tcl language extensions, if these are installed.
393 To exit from a tcl session use the command:
397 Online help is provided with tcl. To access this, use the following command:
401 Online help is also available for all WOK commands. To display help on a particular WOK command, give the command name followed by the -h flag, as in the following example:
406 @subsection occt_wok_3_2 Steps
407 Implementation of an application is based on the following steps:
408 1. Enter the software factory using the command wokcd MyFactory
409 2. Enter a workshop using the command wokcd MyWorkshop
410 3. Open a workbench using the command wokcd MyWorkbench
411 4. Search for the data types required among the existing OCCT libraries
412 5. Define one or more packages which will contain the classes
413 6. Define new data types as classes
414 7. Implement the methods of those classes in C++
415 8. Implement any package methods in C++
416 9. Unite the test packages
417 10. Define any nocdlpacks (if any)
418 11. Test the components
420 **Note:** Steps 1-3 can be performed with a single WOK command:
422 > wokcd MyFactory:MyWorkshop:MyWorkbench
425 @subsection occt_wok_3_3 Getting Started
426 @subsubsection occt_wok_3_3_1 Entity Names
427 Before you start, the following restrictions on WOK entity names must be noted:
428 * Entity names may only contain alphanumeric characters and dashes.
429 * Entity names must be unique within a hierarchy. For example, you must not have two workbenches called MyBench in the same Workshop. Likewise, you may not have a workshop called CSF in a factory of the same name.
430 * Do not use upper and lower case characters to distinguish between two entity names, for example ENT1 and eNt1. This restriction is for reasons of portability.
431 * Parcel names must be unique.
433 @subsubsection occt_wok_3_3_2 Entering the Factory
434 When you start work you go to the factory using the following command:
438 @subsubsection occt_wok_3_3_3 Creating a New Workshop
439 If you don’t want to work in a workshop already present in the factory, you can create a new one. To do this, use the following command:
441 > screate –d <MyWorkshop>
443 This creates the new workshop **MyWorkshop** in the current factory. To create the same workshop in a different factory use the syntax below:
445 > screate –d <MyFactory:MyWorkshop>
448 When you create a new workshop, it is empty.
450 @subsubsection occt_wok_3_3_4 Selecting Parcels
451 When you create a workshop, you select existing OCCT resources, for example, parcels, to use in it. To do this, you create the workshop and add the parcels using the following syntax:
453 > screate –d <MyWorkshop> -DparcelConfig=Parcel1,Parcel2…
455 To display available OCCT resources, in other words, to see what parcels are available, you use the following command:
457 Winfo –p <WarehouseName>
459 **Note:** parcel configuration rarely needs to change. If it does, only the workshop administrator should make them.
460 @subsubsection occt_wok_3_3_5 Opening a Workshop
461 To open a workshop, you use the following command:
465 @subsubsection occt_wok_3_3_6 Creating a New Workbench
466 When you create a new workshop, it is empty. In other words, it does not contain any workbenches.
467 To create the root workbench of a new workshop, you use the following command:
469 > wcreate -d <MyWorkbench>
471 This creates a tree of workbench subdirectories.
472 If workbenches already exist in your workshop, but you do not want to work in any of these, create a new workbench as a child of an existing one. You do this using the following syntax:
474 > wcreate –d <MyWorkbench> -f <ParentWorkbench>
476 @subsubsection occt_wok_3_3_7 Opening a Workbench
477 To open a workbench, you use the command below:
479 > wokcd <MyWorkbench>
481 This automatically takes you to the root directory of the workbench
483 @subsubsection occt_wok_3_3_8 Using Existing Resources
484 Before creating new data types, you should look for existing components that you can reuse. In particular, you should look through the existing resources of your Open CASCADE Technology platform to see if any of the required components already exist, or if any existing generic components can be suitably implemented. This search can be conducted using the online documentation. You should note the packages and classes, which you can reuse.
485 @subsection occt_wok_3_4 Creating Software Components
486 @subsubsection occt_wok_3_4_1 Creating a Package
487 To develop new software components, you usually need to create one or more packages. You do this, by using the following command:
489 > ucreate –p <MyPackage>
491 Because the key -p defines the default value for the *ucreate* command, you do not need to specify it. The following syntax, for example, will also create a package:
493 > ucreate <MyPackage>
495 #### Enter a Package or other Development Unit Structure
497 Enter the package or any other development unit structure using the *wokcd* command as in the syntax below:
501 The current directory is now:
503 MyWorkbenchRoot/src/MyPackage
506 #### Writing the Package and Class Specifications in CDL
508 Write the descriptions of the software components in CDL using an editor of your choice. Write each class in its own .cdl file and write one .cdl file (MyPackage.cdl) to specify the package that contains those classes.
510 #### CDL Compilation of the Package
512 Compile and check the package and its classes using:
516 This command also extracts the C++ header files (.hxx) and stores them in the derived files directory.
518 #### Implementing Methods in C++
520 A package will contain methods, which may be:
524 Extract **prototypes** for the C++ methods using the following command:
526 > umake -o xcpp.fill -o xcpp.template
529 You should not confuse this syntax with the template feature of C++ used to implement the genericity.
530 The *umake -o xcpp.template* command creates a skeleton C++ file for:
532 * All the package methods.
533 The packages methods will be created in a file called *package.cxx.template*. This command is not included in the umbrella command *MyPackage*.
534 You will need to use an editor to implement these methods in C++.
537 #### Compiling the Package
539 To compile the package, use the command:
541 > umake -o obj <MyPackage>
543 If you do not specify a package, the current development unit is compiled.
545 #### Sample Construction of a Package
547 In the following example a workbench named **MyWb** is created as a child of an existing workbench **Topo**. MyWb is used for working on the package **MyPack**. Commands preceded by an asterisk below are used only once per session:
548 1. Create the MyWb workbench as a child of Topo.
550 > wcreate MyWb -f Topo -d
552 2. Create MyPack in MyWb.
556 3. Move to the source directory of MyPack.
560 4. Edit the source files (MyPack.cdl etc.). You do this outside tcl, using the editor of your choice.
561 5. Start the extraction of MyPack.
565 6. Generate the .cxx templates for MyPack: MyPack.cxx.template
567 > umake -o xcpp.fill -o xcpp.template -t
569 7. Edit the source files (MyPack.cxx etc). You do this outside tcl, using the editor of your choice.
571 **Note** that *umake* command used without arguments will carry out all the above *umake* steps. You can also use it with specific arguments as above to go through the development process step by step.
575 * Primary Files for a Package
576 + \<Package\>.cdl Primary package file.
577 + \<Package\>_\<Class\>.cdl Primary class file.
578 * C++ Files for a Package
579 + \<Package\>.cxx Primary package source file.
580 + \<Package\>_[1..9[0..9]*].cxx Secondary package source files.
581 + \<Package\>.lxx Inline package methods source file.
582 + \<Package\>.pxx Private instructions source file.
583 * C++ Files for a Class
584 + \<Package\>_\<Class\>.cxx Primary class source file.
585 + \<Package\>_\<Class\>_[1..9[0..9]*].cxx
586 * Secondary class source files.
587 + \<Package\>_\<Class\>.gxx Generic class methods source file. This is an alternative to the .cxx file(s), you do not have both.
588 + \<Package\>_\<Class\>.lxx Inline methods source file.
589 + \<Package\>_\<Class\>.pxx Private instructions source file.
590 * Derived C++ Files for a Package
591 + \<Package\>.hxx User header file.
592 + \<Package\>.ixx User header file included in \<Package\>.cxx.
593 + \<Package\>.jxx User header file included in \<Package\>_[1-9].cxx.
594 * Derived C++ files for a class
595 + \<Package\>_\<Class\>.hxx User header file.
596 + \<Package\>_\<Class\>.ixx User header file included in \<Package\>_\<Class\>.cxx.
597 + \<Package\>_\<Class\>.jxx User header file in \<Package\>_\<Class\>_[1..9[0..9]*].cxx.
598 + Handle_\<Package\>_\<Class\>.hxx Persistent or Transient class header file.
599 + \<Package\>_\<Class\>_0.cxx For instantiated classes.
601 Umake Steps for a Package
602 -------------------------
603 The umake steps for development units of package type are explained below.
604 * *src* Processes the file *MyPackage.cdl* to generate a list of all the CDL files in the development unit. Processes FILES to list source files.
605 * *xcpp.fill* Compiles the internal data structure to prepare for subsequent extractions.
606 * *xcpp.src* Lists the source files (.cxx, .gxx, .lxx) deduced from the CDL files.
607 * *xcpp.header* Extracts header files for the classes in the development unit.
608 * *xcpp.template* Extracts a template for implementation of methods. (Hidden step.)
609 * *obj.inc* Based on the list of source files generated by the src and xcpp.src steps, this step publishes the include files for the development unit so that other units can use them.
610 * *obj.cgen* Processes the source files to generate code.
611 * *obj.comp* Compiles each file that can be compiled.
612 * *obj.idep* Generates dependency information for the unit. This comprises:
613 + Includes performed by unit compilation (Unit.MakeState)
614 + Implementation dependencies in terms of the unit suppliers (Unit.ImplDep)
615 * *obj.lib* Generates the shared library for the development unit.
617 @subsubsection occt_wok_3_4_2 Creating a Nocdlpack
618 If your executable requires the use of a nocdlpack, create a development unit of nocdlpack type and move to its structure using the commands below:
620 > ucreate -n <MyNoCDLPack>
621 > wokcd <MyNoCDLPack>
623 Use an editor to write *FILES*, which is a nomenclature file for a nocdlpack. This file must list all the C, C++, Fortran, lex, and yacc sourcs files (one per line).
624 Build the nocdlpack using the following command:
626 > umake [<MyNoCDLPack>]
628 **Note** that a nocdlpack unit is not intended to perform tests. Use an executable unit instead.
631 #### Sample Construction of a Nocdlpack
633 In the following example a nocdlpack *MyNocdlpack*, is created. Commands preceded by an asterisk below are used only once per session:
634 1. \*Create MyNocdlpack in MyWb.
636 > ucreate -n <MyNoCDLPack>
638 2. Move to the source directory of MyNocdlpack.
640 > wokcd <MyNoCDLPack>
642 3. Write the FILES list. You do this outside tcl, using the editor of your choice.
643 4. Write the source code.
644 5. Build MyNocdlpack.
646 > umake [<MyNoCDLPack>]
649 #### Umake Steps for a Nocdlpack
651 The *umake* steps for development units of *nocdlpack* type are explained below.
652 * *src* Processes FILES to list source files.
653 * *obj.cgen* Processes the source files to generate code.
654 * *obj.inc* Based on the list of source files, this step publishes the header files for the unit so that other units can use them.
655 * *obj.comp* Compiles each file that can be compiled.
656 * *obj.idep* Generates dependency information for the unit. This comprises:
657 + Includes performed by unit compilation. (Unit.MakeState)
658 + Implementation dependencies in terms of the unit suppliers. (Unit.ImplDep)
659 * *obj.lib* Generates the shared library for the unit.
661 @subsubsection occt_wok_3_3_3 Creating a Schema
662 If the application, which you intend to build, stores data in a file, you need to define a schema for the persistent data types that are known.
664 You create a schema and go to its root directory using the commands:
666 > ucreate -n <MySchema>
669 Using the editor of your choice, write a .cdl file to define the schema. This schema file lists all the packages that contain persistent data types used in the implementation of your application. It has the following format:
673 class <MyClass> from <Package>;
677 #### Building a Schema
679 Compile and check the coherence of the CDL specification for the schema:
683 Extract the C++ description:
687 Compile the C++ description of the schema:
691 Alternatively, the above three steps can all be carried out by one command:
695 #### Sample Construction of a Schema
697 In the following example the schema *MySchema* is created. It contains all the schemas of the persistent classes of your own packages and the packages they depend on. Commands preceded by an asterisk below are used only once per session:
698 1. Create MySchema in MyWb.
700 > ucreate -s MySchema
702 2. Move to the source directory of MySchema.
706 3. Edit the source file MySchema.cdl. You do this outside tcl, using the editor of your choice.
707 4. Derive implementation files.
711 5. Derive application schema files.
715 6. Compile the schema.
722 * Primary Files for a Schema
723 + *\<Schema\>.cdl* Primary schema file.
724 * Derived C++ Files for a Schema
725 + *\<Schema\>.hxx* User header files.
726 + *\<Schema\>.cxx* Schema implementation files.
727 + *\<Sch_MyPack_MyClass\>.cxx* Schema implementation files.
729 #### Umake Steps for a Schema
731 The umake steps for development units of schema type are explained below.
732 * *src* Processes MySchema.cdl to generate a list of CDL files for the development unit. Processes the FILES file to list source files.
733 * *xcpp.fill* Compiles the internal data structure to prepare for subsequent extractions.
734 * *xcpp.sch* Extracts the schema implementation code.
735 * *obj.comp* Compiles the extracted files that can be compiled.
736 * *obj.lib* Generates the shared library for the unit.
737 * *obj.idep* Generates dependency information for the schema.
739 @subsection occt_wok_3_5 Building an Executable
740 @subsubsection occt_wok_3_5_1 Creating an Executable
741 To make an executable from one or more of the packages, which you have created, write a .cdl file to specify the packages to use.
743 #### Writing an Executable
745 Refer to the **CDL User’s Guide** for full details. A simple example is given below.
748 executable <MyExec> // the executable unit
750 executable myexec // the binary file
754 myexec; // the C++ file
755 end; // several binaries can be specified in one .cdl file.
763 Write the C++ file(s). For the example above you write two files: *myexec.cxx* and *myex2.cxx*.
765 #### Building the Executable
767 To build the executable, use the command *umake*
769 #### Construction of an Executable
771 In the following example an executable, *MyExec*, is created in the workbench *MyWb*. Commands preceded by an asterisk below are used only once per session:
772 1. \*Create MyExec in MyWb.
776 2. Move to the source directory of *MyExec*.
780 3. Edit the cdl source file *MyExec.cdl*. You do this outside tcl, using the editor of your choice.
781 4. Edit the C++ files *AnExe.cxx*, etc. You do this outside tcl, using the editor of your choice.
786 6. Run the executable file.
792 #### Executable Files
794 | \<Exec\>.cdl | Primary executable file |
795 | \<AnExe\>.cxx | Source C++ file |
796 | \<AnExe\>_[1-9].cxx | Other source C++ files |
798 #### Umake Steps for an Executable
800 The umake steps for development units of executable type are explained below.
801 * *src* Processes MyExe.cdl to generate a list of CDL files for the development unit. Processes FILES to list source files.
802 * *src.list* Based on MyExe.cdl, works out the list of parts and the source files involved for each part.
803 * *exec.comp* Compiles the files that can be compiled for each part of the executable.
804 * *exec.idep* Generates dependency information for each part of the executable.
805 * *exec.libs* Computes full implementation dependency to prepare for linking for each part of the executable.
806 * *exec.tks* Performs toolkit substitution according to TOOLKITS for each part of the executable.
807 * *exec.link* Links each part of the executable.
809 @subsection occt_wok_3_6 Test Environments
810 @subsubsection occt_wok_3_3_1 Testing an Executable
811 To test an executable, you create an executable development unit and move to its structure.
813 When you write the .cdl file for your test executable, specify the packages to test, for example:
815 executable MyTest // the executable unit
817 executable mytest1 // the binary file
819 mytest1; //the C++ file
820 end; // several binaries can be specified in one .cdl file.
827 Write the C++ test file(s), in the example, *mytest1.cxx* and *mytest2.cxx*.
828 #### Building the Executable
830 To build the executable use the command:
835 #### Setting up a Test Environment
837 To set up a test environment, move to the <i>/drv</i> subdirectory that corresponds to the current profile (e.g. <i>/MyExec/drv/DFLT/sun</i>) and run the executable test file.
843 The command *wokenv* is used with -s option to configure the test environment.
844 The command *wokenv –s* uses the current workbench to decide what actions are needed to configure the tcl shell for use as your test environment.
845 WOK sets the following environment variables:
847 * <i>$STATION</i> - The current station.
848 * <i>$TARGET_DBMS</i> - The current database platform.
849 * <i>$PATH</i> - The current path, plus the bin directories of the parcels.
850 * <i>$LD_LIBRARY_PATH</i> The current path, plus the lib directories of the parcels.
851 WOK then sets a variable for each parcel listed in the parcel configuration of the current workshop. This variable is the original name of the delivery unit in the uppercase, with the suffix *HOME*.
852 * <i>$ORIGDELIVUNITHOME</i> is set as the root directory of the parcel.
853 WOK then sources the following files:
854 * MyFactory.tcl, found in the admin directory of the factory.
855 * MyWorkshop.tcl found in the admin directory of the workshop.
856 Then for each Workbench, WOK sources according to the hierarchy of the workbenches:
857 * Workbench.tcl, found in the /Adm directory of the workbench.
859 After the environment is set up, you are at a C shell prompt and can run the executable.
861 **Note** Environment variables are only set when the command is used with the option <i>-s</i>. Thus, if you change a workbench or a factory within WOK and then return to the test environment you must use *wokenv -s* to ensure that the set environment variables configuration is correct for the current WOK state.
862 The configuration actions that WOK performs can be written to a file and saved as a script. You can then edit this script to suit it to your own needs, and generate a personalized test environment.
864 To create the script file use the following command:
866 > wokenv -f <ScriptFile> -t csh
868 This command generates a file, ScriptFile, which configures a C shell to mirror the current WOK environment. An example script file is given below.
871 setenv TARGET_DBMS *DFLT*
872 setenv KERNELHOME */adv_22/WOK/BAG/KERNEL-K1-2-WOK*
873 setenv LD_LIBRARY_PATH */adv_22/WOK/BAG/wok-K1-2/lib/sil:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/lib/*
874 setenv PATH */usr/tcltk/bin:/usr/bin:/bin:/usr/bin/X11:/lib:.:/SGI_SYSTEM/util_MDTV/factory_proc:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/bin/*
875 source /adv_22/WOK/BAG/KERNEL-K1-2-WOK/adm/Kernel.csh
878 @subsection occt_wok_3_7 Building a Toolkit
879 @subsubsection occt_wok_3_7_1 Creating a Toolkit
881 You create and enter a toolkit development unit using the following commands:
883 > ucreate -t <TKMyToolkit>
884 > wokcd <TKMyToolkit>
887 #### Write the Nomenclature File for the Toolkit
889 Using an editor, write a nomenclature file called PACKAGES which lists all the packages, one per line, that make up the toolkit. Add PACKAGES to FILES.
890 Build the shareable library for this toolkit as follows:
892 \> umake [<TKMyToolkit>]
894 **Note:** when one of the packages in the toolkit is modified, recompile the toolkit. A package should belong to one toolkit only.
896 #### Sample Construction of a Toolkit
898 In the following example, the toolkit **TKMyToolkit** is created. Commands preceded by an asterisk are used only once per session:
899 1. \*Create MyToolkit in MyWb.
901 \> ucreate -t TKMyToolkit
903 2. Move to the source directory of MyToolkit.
907 3. Edit the nomenclature files, PACKAGES and FILES. You do this outside tcl, using the editor of your choice.
908 4. \*Create the library for MyToolkit
913 #### Umake Steps for a Toolkit
915 The umake steps for development units of toolkit type are explained below.
916 * *src* Processes FILES to list source files.
917 * *lib.list* Works out the objects and archive library to add to the toolkit shared library.
918 * *lib.limit* Manages the build process strategy within the limitations of a particular platform.
919 * *lib.arch* Builds archives according to the building strategy.
920 * *lib.uncomp* Decompresses third party archives.
921 * *lib.arx* Extracts object files from archives.
922 * *lib.build* Generates the shared library for the toolkit.
924 Building strategy depends on the platform. The following step sequences apply:
940 #### The TOOLKITS File
942 When executables are compiled, a TOOLKITS file is used to determine which toolkits are included. This file is located in the src directory of the entity being compiled. The process is as follows:
943 * If no TOOLKITS file has been found, all toolkits are candidates for substitution. To find out which toolkits are candidates, use the command *w_info -k*.
944 * If an empty TOOLKITS file has been found, there is no toolkit candidate for substitution.
945 * If a non-empty TOOLKITS file has been found, only the toolkits listed in this file are candidates for substitution.
947 #### Toolkit Substitution
949 Toolkit substitution is performed as follows:
950 1. MyEngine uses A, B and C;
951 2. The toolkit TK provides A and D; D uses E;
952 3. Compilation of *MyEngine* includes TK, B C and E.
954 Here, for simplicity, assume that additional toolkits are not substituted for B, C and E.
956 @subsection occt_wok_3_8 Building a Delivery Unit
957 @subsubsection occt_wok_3_8_1 Creating a Delivery Unit
959 \> ucreate -d <MyDeliveryUnit>
962 #### Writing the COMPONENTS File
964 Create a file named COMPONENTS in the src subdirectory of the delivery development unit. List in this file the prerequisites of the delivery and the components that are part of the delivery. Use the syntax shown below.
965 Note that keywords and default options are shown in bold.
967 | **Name** | ParcelName |
971 | **Requires** | DeliveryName\* |
972 | **Package** | MyPack **[CDL][LIBRARY][INCLUDES][SOURCES]** |
973 | **Nocdlpack** | MyNcdl **[LIBRARY][INCLUDES][SOURCES]** |
974 | **Executable** | MyExec **[CDL][DYNAMIC][SOURCES]** |
975 | **Interface** | MyIntf **[CDL][STUB_SERVER][SOURCES]** |
976 | **Client** | MyClient **[CDL]**[STUB_CLIENT][SOURCES] |
977 | **Engine** | MyEng **[CDL][DYNAMIC][SOURCES]** |
978 | **Schema** | MyShma **[CDL][LIBRARY][SOURCES][DOC]** |
979 | **Toolkit** |MyTk **[LIBRARY][SOURCES]** |
980 | **Get** | DevelopmentUnitName::Type\:\:\:File |
982 \* Without mention of the version
984 If no keywords are specified then all default arguments shown in bold are taken into account. To select arguments, list the ones required explicitly. The arguments are explained below:
985 * **Name** The full name of the current delivery, including a version number. This is the name of the parcel.
986 * **Put path** Requires that the delivery be inserted in the user path (bin directory).
987 * **\[CDL\]** Copy the cdl files to the delivery.
988 * **\[LIBRARY\]** Generate the static library. Copy the shareable library to the delivery. Copy the list of objects of the library.
989 * **\[INCLUDES\]** Generate includes.origin. Copy the includes to the delivery. Copy the ddl to the delivery.
990 * **\[DYNAMIC\]** Select to copy the static or dynamic executable file.
991 * **\[SOURCES\]** Copy the source files.
993 #### Build the Delivery
995 To build the delivery unit, use the command:
997 \> umake <MyDeliveryUnit>
999 The result of building a delivery unit is a **parcel**, which can be installed in a warehouse and used by other workbenches.
1001 #### Sample Delivery of a Parcel
1003 In the following example a delivery is created, compiled and made into a parcel. Commands preceded by an asterisk below are used only once per session:
1004 1. Move to the root workbench under which the parcel is to be made.
1008 2. \*Create MyDelivery in MyRootwb.
1010 > ucreate -d MyDelivery
1012 3. Move to the source directory of MyDelivery.
1016 4. Use an editor to list all the prerequisites and components of the delivery in the COMPONENTS files using the appropriate syntax.
1017 5. Build MyDelivery.
1021 The output of the umake process is a parcel
1023 #### Umake Steps for a Delivery Unit
1025 The umake steps for development units of type delivery are explained below.
1026 * *src* Processes FILES to list source files.
1027 * *base* Creates directories, defines the list of units, copies the parcels and the release notes.
1028 * *get.list* Lists files to get (using Get, Resource).
1029 * *get.copy* Copy the files listed by get.list.
1030 * *cdl.list* Lists CDL files to copy.
1031 * *cdl.copy* Copies the files listed by cdl.list.
1032 * *source.list* Lists units from which sources are to be copied.
1033 * *source.build* Creates a file for sources (in the format: unit.type.Z).
1034 * *inc.list* Lists includes to copy.
1035 * *inc.copy* Copies files listed by inc.list.
1036 * *lib.shared* Works out the inputs for building or copying shareable libraries.
1037 * *lib.shared.build* Copies or builds (depending on the platform) the shareable libraries.
1038 * *lib.server.list* Lists interface files to copy.
1039 * *exec.list* Lists inputs for executable delivery.
1040 * *exec.build* Creates executable in the parcel.
1041 * *files* Works out the list of files delivered in the parcel.
1043 @subsubsection occt_wok_3_8_2 Installing a Parcel
1044 You open the root workbench of the workshop where you want to install the parcel using the following command:
1046 \> wokcd <MyWorkshop>
1048 To install the parcel, use the following syntax:
1050 \> pinstall <MyParcel>
1053 @subsection occt_wok_3_9 Working with Resource
1055 ### Building a Resource
1057 There is a single umake step for development units of resource type.
1058 * *src* Processes FILES to list source files.
1060 @subsection occt_wok_3_10 Java wrapping
1061 @subsubsection occt_wok_3_10_1 Creating an interface
1063 To create an interface development unit and move to its structure, use commands:
1065 \> ucreate -i <MyInterface>
1066 \> wokcd <MyInterface>
1069 ### Writing an Interface
1071 Having created the interface, you select the classes and packages that you wish to make available for Java wrapping in the jni units. Use an editor of your choice to write a .cdl interface file that specifies these exported services. This file has the format:
1074 interface MyInterface
1084 ### Building an Interface
1086 To make the services of the interface available for further wrapping, build the interface, using the command:
1088 > umake [<MyInterface>] -o src
1091 ### Sample Construction of an Interface
1093 In the following example a workbench, *MyWb*, is used for working on the interface *MyInterface*. Commands preceded by \* (asterisk) are used only once during a session.
1095 1. \*Create MyInterface in MyWb.
1097 >ucreate -i MyInterface
1099 2. Move to the source directory of MyInterface.
1103 3. Edit the source file MyInterface.cdl. You do this outside tcl, using an editor of your choice.
1104 4. Build the interface.
1111 _<Interface>.cdl_ is the primary interface file.
1113 ### Umake Steps for an Interface
1115 The umake steps for development units of type interface are explained below.
1117 * *src* - processes *MyInt.cdl* to list the CDL files for the development unit. Processes the FILES file to list source files.
1119 **Note** Make sure you only use the *src* step of umake. Using umake without arguments will lead to an attempt of launching other steps relevant to the interface unit. However these steps will fail and anyway are not required for use in Java wrapping.
1121 @subsubsection occt_wok_3_10_2 Creating a jni
1122 To create a development unit of type jni and move to its structure, use commands:
1124 > ucreate -j <MyJni>
1130 Use an editor to write a .cdl file that specifies the interface or interfaces required by the jni. This file has the following format:
1134 {interface MyInterface;}
1135 {interface YourInterface;}
1141 To wrap services exported by the interfaces to Java, build the jni, using the command:
1146 ### Sample Construction of a Jni
1148 In the following example a workbench, *MyWb*, is used for working on the jni, *MyJni*. Commands preceded by \* (asterisk) are used only once during a session.
1150 1. \*Create MyJni in MyWb.
1154 2. Move to the source directory of *MyJni*.
1158 3. Edit the source file *MyJni.cdl*. You do this outside tcl, using an editor of your choice.
1159 4. Derive Java files (.java and .class files) and C++ files (.h and .cxx) used for wrapping.
1163 5. Compile the sources.
1167 6. Link the object files.
1172 Primary jni file is *Jni.cdl*
1174 Derived Java files for a Jni are:
1175 * \<Package\>_\<Class\>.java - Java source file of the class to be wrapped.
1176 * \<Package\>_\<Class\>.class - Compiled java source file.
1178 Derived C++ files for a Jni are:
1179 * \<Jni\>_\<Package\>_\<Class\>_java.h - Include file for the C++ implementation of JNI.
1180 * \<Jni\>_\<Package\>_\<Class\>_java.cxx - C++ implementation of JNI.
1182 ### Umake Steps for a Jni
1184 The umake steps for development units of type jni are explained below.
1185 * *src* Processes MyJni.cdl to list the CDL files for the development unit. Processes the FILES file to list source files.
1186 * *xcpp.fill* Compiles the internal data structure to prepare for subsequent extractions.
1187 * *xcpp.client* Extracts the services declared in included interface unit(s) into Java and creates .java and \*_java.cxx files.
1188 * *xcpp.javac* Compiles .java files into .class files.
1189 * *xcpp.javah* Creates .h header files.
1190 * *obj.comp* Compiles generated C++ files.
1191 * *obj.idep* Generates dependency information for the unit.
1192 * *exec.libs* Computes full implementation dependency to prepare for linking.
1193 * *exec.tks* Performs toolkit substitution.
1194 * *exec.link* Generates the shared library for the development unit.
1196 @subsection occt_wok_3_11 More Advanced Use
1197 @subsubsection occt_wok_3_11_1 Default User Profile
1198 There is a default user profile. If you wish to change this profile the command *wokprofile* is available.
1200 An example profile is given below.
1202 Info : Profile in : WOK:k1dev:ref
1203 Info : Extractor : DFLT
1204 Info : Compile Mode : Optimized
1205 Info : Station Type : sil
1207 @subsubsection occt_wok_3_11_2 Changing Parcel Configuration
1208 Parcel configuration rarely needs changes. However, if you do need to modify the list of resources, you can do so by editing the admin parameter file of the factory. This file is found in the admin directory of the factory and is named after the workshop. It has the suffix .edl. Its full name has the following format:
1213 Move to the admin directory of the factory:
1215 \> wokcd <MyFactory> -PAdm
1218 Then use the editor of your choice to edit the admin parameter file, MyWorkshop.edl.
1219 In this file, the parcel configuration is defined by an entry of the form:
1221 \@set %<MyWorkshop>_ParcelConfig = “Parcel1 Parcel2...Parceln”;
1223 The resources are listed within quotation marks. They are separated by spaces.
1224 Edit this list as required. Save the file and close it.
1225 To validate and take into account your changes use the command:
1229 This command closes and reopens all the entities. Without the -a option, *wokclose* only applies to the current entity.
1231 @section occt_wok_4_ Available Services
1232 @subsection occt_wok_4_1 Synopsis
1233 WOK provides sets of services, which can be grouped according to the entity they apply to:
1241 * Source Management Services
1243 @subsubsection occt_wok_4_1_1 Common Command Syntax
1247 All WOK commands follow a common naming convention. This is based on a set of common command names and a group of prefixes, which denote entity type. The command name takes a prefix representing the entity to which it applies.
1248 The following prefixes exist:
1251 * w: for workbenches
1252 * u: for development units
1255 * wok: for commands that apply to any type of entity
1256 These prefixes are followed by a command that determines the action to be executed. Examples of such commands are:
1257 * create: create an entity
1258 * rm: delete an entity
1259 * info: request information
1260 Consequently, the command ucreate creates a development unit. The command wrm removes a workbench.
1262 #### Command Options
1264 All command options are expressed using a dash (-) followed by one or more key letters and, if applicable, an argument. For example:
1266 > umake -f -o <argument> MyUnit
1268 The compact version of this syntax is also valid:
1270 umake -fo argument MyUnit
1272 This syntax conforms to the POSIX recommendations for UNIX commands.
1273 For all commands, there is a –h option, which displays help on usage.
1275 #### Presentation of Commands
1277 The general syntax of the commands is presented in this document as follows:
1279 CommandName [option(s) [<argument(s)>] [<Entity>]]
1281 Consequently, there are four general cases for a command:
1283 CommandName <Entity>
1284 CommandName <option(s)> [<argument(s)>] <Entity>
1285 CommandName <option(s)> [<argument(s)>]
1288 **Note** a few commands described in this chapter do not completely respect this syntax; for example, *create* and *rm*.
1290 As a rule, where an _\<EntityPath\>_ is given as an argument it specifies which entity the command applies to. Where no _\<EntityPath\>_ is specified, the command applies to the nearest appropriate entity. The *create* and *rm* commands are notable exceptions: you **must** specify an entity path with these commands.
1292 @subsection occt_wok_4_2 General Services
1293 General services are commands that apply to any entity manipulated by WOK. They are used for:
1295 * Managing parameters
1296 * Managing profiles.
1298 @subsubsection occt_wok_4_2_1 wokcd
1302 wokcd -P <ParamSuffix> [<EntityPath>]
1305 Navigates between different WOK entities and changes the current working directory. Without any arguments wokcd lists the current position (the WOK equivalent of ‘pwd’). With an argument, wokcd moves to the specified location.
1307 * _\<EntityPath\>_ Moves to the home directory of the entity specified by \<EntityPath\>, i.e. moves to the location given by the parameter: %wokcd \<EntityPath\>_Home.
1308 * _-P \<ParamSuffix\> [\<EntityPath\>]_ Moves to the \<ParamSuffix\> directory of the entity specified by \<EntityPath\>. i.e. moves to the location given by the parameter: %\<EntityPath\>_\<ParamSuffix\>. If no entity path is specified, this command moves to the \<ParamSuffix\> directory of the current entity.
1310 Possible values for \<ParamSuffix\> are: Home, Adm and Src.
1311 Use the following commands to change directories within a development unit:
1312 * **wsrc** To access the source files.
1313 * **winc** To access the include files.
1314 * **wobj** To access objects.
1315 * **wlib** To access shareable libraries.
1316 * **wbin** To access executables.
1317 * **wadm** To access the workbench administration files.
1321 *wokcd* - Lists the current position.
1323 *wokcd MODEL:GTI:gti:gp* - Moves to the home directory of the gp package of the gti workbench in the GTI workshop in the MODEL factory.
1325 *wokcd -P Adm* - Moves to the administration directory of the current entity.
1328 @subsubsection occt_wok_4_2_2 wokclose
1332 Closes and reopens entities, i.e. reloads them into memory thus taking any changes into account.
1333 Option <i>-a</i> closes and reloads all entities.
1340 Closes and reopens the current entity.
1344 Closes and reopens all the entities.
1345 @subsubsection occt_wok_4_2_3 wokenv
1347 wokenv -f <ScriptFile> -t csh
1349 Creates the file \<ScriptFile\>. This file is a script, which configures a C shell to mirror the current WOK environment. See the <a href="#occt_wok_3_6">Test Environments</a> section for more details.
1351 * -f \<ScriptFile\> - Specifies the name of the file to produce.
1352 * -t csh - Produces a file for configuring a C shell.
1353 * -s - Sets up environment variables for application launching.
1357 > wokenv -f MyTestEnvScript -t csh
1359 Generates the shell script *MyTestEnvScript* to configure a C shell so that it mirrors the current WOK environment.
1360 @subsubsection occt_wok_4_2_4 wokinfo
1362 wokinfo -<option> [<EntityPath>]
1363 wokinfo -<option> <argument> [<EntityPath>]
1365 Displays information about _\<EntityPath\>_. The information displayed is common to all the entities. If no _\<EntityPath\>_ is specified, information about the current entity is returned.
1366 This command can be used to find the path of a file.
1368 * -t - Returns the type of entity (factory, warehouse, parcel, workbench, development unit).
1369 * -T - Lists the types of files known in the entity.
1370 * -f - Gets factory from path.
1371 * -N - Gets the nesting path, i.e. where the current entity is nested.
1372 * -n - Gets entity name.
1373 * -P - Gets parcel from path.
1374 * -s - Gets workshop from path.
1375 * -u - Gets development unit from path.
1376 * -W - Gets warehouse from path.
1377 * -w - Gets workbench from path.
1378 * -x - Tests if entity exists.
1379 * -d \<type\> - Gets type definition.
1380 * -a \<type\> - Gets type arguments.
1381 * -p \<type\>:\<filename\> - Gets the path for a file, which is of the type type that depends on %File. In other words, the path for a file of this type depends on the file name, \<filename\>.
1382 * -p \<type\> - Gets the path for a file, which is of the type \<type\> that is not %File dependent, for example EXTERNLIB.
1387 wokinfo -p source:gp.cdl MODEL:GTI:gti:gp
1389 Returns the path of the source file gp.cdl in the MODEL:GTI:gti:gp.
1391 wokinfo -t MODEL:GTI:gti:gp
1393 Returns the development unit.
1395 @subsubsection occt_wok_4_2_5 woklocate
1397 woklocate -<option> <argument> [<WorkbenchPath>]
1398 woklocate -P [<WorkbenchPath>]
1400 Using WorkbenchPath as the starting point, this command locates files associated with the development unit and specified by the argument argument.
1402 * -f \<Unit:Type:File\> - Locates a file and gives its ID.
1403 * -p \<Unit:Type:File\> - Locates a file and gives its path.
1404 * -u \<Unit\> - Locates a development unit.
1405 * -P - Displays all available WOK public types.
1412 Displays the location of the file, MyFile.
1414 @subsubsection occt_wok_4_2_6 wokparam
1416 wokparam -<option> [<EntityPath>]
1417 wokparam -<option> <argument> [<EntityPath>]
1419 Queries system parameters such as variables and templates. For more information about parameters refer to the appendix *Parameters and EDL Files* at the end of this User’s Guide. If an \<EntityPath\> is specified this indicates the entity to which the command applies.
1421 * -L - Lists the directories used to search for the parameter files.
1422 * -C - Displays the subclasses list.
1423 * -a \<TemplateName\> - Gets arguments for the template TemplateName.
1424 * -e \<ParamName\> - Evaluates the parameter ParamName.
1425 * -F \<ClassName\> - Displays the files comprising the definition of the class *ClassName*.
1426 * -l \<Class\> - Lists parameters concerning class (prefix) class.
1427 * -S \<FileName\> - Finds the first file FileName in the list of directories cited afterwards.
1428 * -t \<Name\> - Tests if the variable Name is set.
1429 * -v \<ParamName\> - Displays the value of the parameter *ParamName*.
1430 * -s \<Name\>=\<Value> Reserved for advanced use. Sets the variable *Name* to value *Value*.
1431 * -u \<Name\> Reserved for advanced use. Unsets the variable Name.
1436 wokparam -L MODEL:GTI:gti
1438 Returns a list of directories used for parameters by the gti workbench.
1442 Locates the nearest CSF.edl file used by the current entity.
1444 wokparam MODEL:GTI:gti:gp -e %WOKUMake_Steps
1446 Displays the value of the _\%WOKUMake_Steps_ parameter in the *gp* package. The _\%WOKUMake_Steps_ parameter contains a description of the steps used by umake.
1447 @subsubsection occt_wok_4_2_7 wokprofile
1450 wokprofile -<option> [<argument>]
1452 Modifies session parameters. This command changes the mode of the current compilation and the profile of the current database. It also displays the current value of the session parameters. If no argument is specified, it displays the values of different parameters in the current session as well as the current position *wokprofile -v*.
1454 * -b - Returns the current database profile (OBJS, DFLT).
1455 * -d - Switches to compilation with debug.
1456 * -m - Returns the current compilation mode.
1457 * -o - Switches to optimized compilation.
1458 * -s - Returns the current station type
1459 * -v - Switches to wokprofile verbose mode. In this mode all the parameters of the session are displayed. Running this command displays the current/changed profile.
1466 Displays all the session parameters.
1470 Displays the current database profile.
1474 Switches to optimized compilation and displays the parameters of the current session after the change has been made.
1478 Switches to optimized compilation and displays the parameters of the current session after the change has been made. Note that the order in which these options are specified does not affect the result.
1480 @subsection occt_wok_4_3 Services Associated with Factories
1481 There is a dedicated list of commands for the management of factories. The commands to create and destroy factories are reserved for the exclusive use of the site administrator.
1482 * *fcreate* Creates a factory.
1483 * *finfo* Displays information about the factory.
1484 * *frm* Deletes a factory if it is empty.
1486 @subsubsection occt_wok_4_3_1 fcreate
1487 *Reserved for administrator’s use*
1489 fcreate -<option> [-D <Suffix>=<Value>]* <EntityPath>
1491 Creates a factory. The name of the factory to create is specified by EntityPath. You can also specify the entity that will contain the entity to be created.
1493 Once the creation is completed, a file containing the parameters of the creation of the factory is created in the administration directory of the container to which the factory belongs.
1496 The following parameters are mandatory when a factory is created:
1497 * **Adm** - Path name for administration directory
1498 * **Home** - Path name for home directory
1499 * **Stations** - List of supported stations
1500 * **DBMSystems** - List of supported dbms
1501 * **Warehouse** - Name of factory warehouse.
1504 * -P - Propose defaults. Returns a list of default values for the parameters necessary for the creation of the factory. No entity is created if this option is used.
1505 * -d Use default. Uses default values to create the factory.
1506 * -D\<Suffix\>=\<Value\> - Defines parameter(s). Specifies the value to use for the given parameter(s) explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
1511 fcreate -P NewFactoryName
1513 Returns a list of default values for the parameters that are mandatory when creating a factory.
1515 fcreate MyFactory -d -DHome=/fred/myfactory
1517 Creates the factory MyFactory using default values for all mandatory parameters, except for Home, which is set to: /fred/myfactory
1519 @subsubsection occt_wok_4_3_2 finfo
1521 finfo -<option> [<EntityPath>]
1523 Displays details about the factory. If an EntityPath is specified this determines the factory to apply to. If no entity path is given, the command applies to the nearest factory.
1525 * -s - Displays a list of workshops in the factory.
1526 * -W - Displays the name of the warehouse in the factory.
1527 * -S - Displays the name of the source repository.
1534 Displays a list of workshops in the nearest factory.
1538 Displays the name of the warehouse in MyFactory.
1540 @subsubsection occt_wok_4_3_3 frm
1541 *Reserved for administrator’s use*
1545 Deletes the factory specified by EntityPath if it is empty.
1547 Note, that you must not be in the factory you intend to destroy.
1554 Deletes the factory MyFactory provided that it is empty.
1556 @subsection occt_wok_4_4 Services Associated with Warehouses
1557 A warehouse contains the parcels that are available in a factory. There is a dedicated list of commands for management of warehouses.
1558 The commands you use to create and destroy the warehouses are reserved for the exclusive use of the site administrator.
1559 * *Wcreate* - creates a warehouse.
1560 * *Winfo* - displays information about the warehouse
1561 * *Wrm* - deletes a warehouse if it is empty.
1562 * *Wdeclare* - declares a parcel in the warehouse.
1564 @subsubsection occt_wok_4_4_1 Wcreate
1565 *Reserved for administrator’s use.*
1567 Wcreate [-<option>] -D <Suffix>=<Value>* <WarehouseName>
1568 Wcreate -<option> [-D <Suffix>=<Value>]* <WarehouseName>
1570 Creates a warehouse. The name of the warehouse to create is given by *\<WarehouseName\>*. You can also specify the factory that will contain the warehouse.
1571 Once the creation is completed, a file containing the parameters of warehouse creation is in its turn created in the administration directory of the factory to which the warehouse belongs.
1574 The following parameters are mandatory when a warehouse is created:
1575 * **Adm** - Path name for administration directory.
1576 * **Home** - Path name for home directory.
1577 * **Stations** - List of supported stations.
1578 * **DBMSystems** - List of supported dbms.
1581 * -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a warehouse. No entity is created if this option is used.
1582 * -d - (Use defaults.) Uses default values to create the warehouse.
1583 * -D \<Suffix\>=\<Value\> (Define parameter.) Explicitly specifies the value to use for this parameter. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
1588 Wcreate -P MyWarehouse
1590 Returns a list of default values for the parameters that are mandatory when creating a warehouse.
1592 Wcreate MyWarehouse -d
1594 Creates the warehouse *MyWarehouse* using default values for all mandatory parameters.
1595 @subsubsection occt_wok_4_4_2 Winfo
1597 Winfo -p [<EntityPath>]
1599 Displays details about the warehouse and its contents. If an EntityPath is specified, this determines the warehouse to apply to.
1600 Option -p displays the parcels in the warehouse.
1607 Displays a list of parcels in the current warehouse.
1608 @subsubsection occt_wok_4_4_3 Wrm
1609 *Reserved for Administrator’s Use.*
1613 Deletes the warehouse specified by EntityPath if it is empty. You should not be in the warehouse you intend to destroy.
1619 Deletes the warehouse *MyWarehouse* provided that it is empty.
1620 @subsubsection occt_wok_4_4_4 Wdeclare
1621 *Reserved for administrator’s use*
1623 Wdeclare -p<Parcel> [-d] [-D<ParamName>=<Value>]* <House>
1625 Declares the *Parcel*. This command adds the parcel to the list of parcels available in the warehouse House.
1626 Note that a factory has a default list of deliveries (which are represented by parcels) available to it. This list only needs to be modified when moving to a new version of the delivery. This is done using the *Wdeclare* command, and then by editing the .edl file of the appropriate workshop.
1628 The following parameters are mandatory when declaring parcels:
1629 * **Adm** - Path name for administration directory of a parcel.
1630 * **Home** - Path name for home directory of a parcel.
1631 * **Stations** - List of available stations.
1632 * **DBMSystems** - List of available dbms.
1633 * **Delivery** - Delivery name.
1636 * -p \<Parcel\> Defines the name of the parcel to declare. This name must be given with the option.
1637 * -d Creates a parcel using defaults.
1638 * -P Proposes defaults.
1643 Wdeclare -pMyParcel -d MyWarehouse
1645 Adds the parcel MyParcel to the warehouse MyWarehouse.
1647 @subsection occt_wok_4_5 Services Associated with Parcels
1648 A parcel is a receptacle for development units. You use it to group together the units, which comprise a delivery unit. There is a dedicated list of commands for management of parcels. Only the site administrator should perform installation of parcels in a warehouse.
1649 * *pinfo* - displays information about the contents of the parcel
1650 * *pinstall* - installs the parcel in a Warehouse.
1652 @subsubsection occt_wok_4_5_1 pinfo
1654 pinfo -\<option\> [\<ParcelPath\>] - displays details about the contents of the parcel. If *ParcelPath* is specified this determines the parcel to apply to. If no parcel path is specified the command applies to the nearest parcel.
1657 * -d - Displays the delivery contained in the parcel.
1658 * -l - Displays the development units in the parcel.
1659 * -a - Lists the development units in the parcel together with their types.
1666 Displays a list of units in the parcel MyParcel.
1668 @subsubsection occt_wok_4_5_2 pinstall
1669 *Reserved for administrator’s use*
1671 pinstall <ParcelName>
1673 Installs the parcel \<ParcelName\> in the current warehouse. The process of installing a parcel sets up various paths and variables to ensure that the application can locate necessary resources and so on.
1674 The administrator must perform *pinstall* for each platform used.
1681 Installs the parcel *MyParcel* in the current warehouse.
1683 @subsection occt_wok_4_6 Services Associated with Workshops
1684 A workshop is a tree of workbenches using the same parcel configuration. There is a dedicated list of commands for management of workshops. The commands to create and destroy workshops are reserved for the exclusive use of the site administrator.
1685 * *screate* - creates a workshop.
1686 * *sinfo* - displays information about the workshop
1687 * *srm* - deletes a workshop if it is empty.
1689 @subsubsection occt_wok_4_6_1 screate
1690 *Reserved for administrator’s use*
1692 screate [-<option>] {-D<Suffix>=<Value>}* <WorkshopName>
1693 screate -<option> <WorkshopName>
1695 Creates a workshop, \<WorkshopName\>. You can also specify the factory that contains this workshop.
1696 Once the creation is completed, a file containing the parameters for the creation of the workshop is generated in the administration directory of the factory to which it belongs.
1698 The following parameters are mandatory when creating a workshop:
1699 * **Adm** - Path name for administration directory.
1700 * **Home** - Path name for home directory.
1701 * **Stations** - List of supported stations.
1702 * **DBMSystems** - List of supported dbms.
1703 * **ParcelConfig** - List of parcels used.
1704 * **Workbenchlist** - Path name for the list of workbenches.
1707 * -P (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a workshop. No entity is created if this option is used.
1708 * -d (Use defaults.) Uses default values to create the workshop.
1709 * -D \<Suffix\>=\<Value> (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to accept default values for all the mandatory parameters except the parameter(s) explicitly specified here.
1715 screate -P <WorkshopName>
1717 Returns a list of default values for the parameters that are mandatory for creating a workshop.
1719 screate MyFactory:MyWorkshop -d
1721 Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters.
1723 screate -DParcelConfig=Parcel1,Parcel2 MyFactory:MyWorkshop -d
1725 Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters except for *ParcelConfig*, which is set to *Parcel1 Parcel2*.
1727 @subsubsection occt_wok_4_6_2 sinfo
1729 sinfo -<option> [WorkshopName]
1731 Displays details about the workshop. If *WorkshopName* is specified this determines the workshop this command is applied to. If no workshop is specified the command applies to the nearest workshop.
1733 * -w - Displays a list of workbenches in the workshop.
1734 * -p - Displays the parcel configuration of the workshop.
1741 Displays a list of workbenches in the nearest workshop.
1743 @subsubsection occt_wok_4_6_3 srm
1744 *Reserved for administrator’s use*
1748 Deletes the workshop \<WorkshopName\> if it is empty. You must not be in the workshop you intend to destroy.
1755 Deletes the *MyWorkshop* provided that it is empty.
1757 @subsection occt_wok_4_7 Services Associated with Workbenches
1758 A workbench is the place where a developer (or a team of developers) works on a particular product. There is a dedicated list of commands for management of workbenches.
1760 * *wcreate* - creates a workbench.
1761 * *w_info* - displays information about a workbench.
1762 * *wrm* - deletes a workbench if it is empty.
1763 * *wmove* - moves a workbench to a new location.
1765 @subsubsection occt_wok_4_7_1 wcreate
1767 wcreate -f <ParentWB> [-D <Suffix>=<Value>]* <WBName>
1768 wcreate -f <ParentWB> -P|d [-D <Suffix>=<Value>]* <WBName>
1769 wcreate -f <ParentWB> -P|d <WBName>
1771 Creates the workbench \<WBName\> as a child of the workbench \<ParentWB\>. The result of this creation is a directory structure.
1772 Compared to the creation of other entities, creating a workbench requires an additional piece of information: you must specify the parent of the workbench to create.
1773 Once the creation is completed, a file containing the parameters of the creation of this workbench is created in the administration directory of the workshop that contains it.
1775 The following parameters are mandatory when creating a workbench:
1776 * **Adm** Path name for administration directory.
1777 * **Home** Path name for home directory.
1778 * **Stations** List of supported stations.
1779 * **DBMSystems** List of supported dbms.
1782 * -f - Specifies the parent workbench.
1783 * -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of the workbench. No entity is created if this option is used.
1784 * -d - (Use defaults.) Uses default values to create the workbench.
1785 * -D \<Suffix\>=\<Value\> - (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
1790 wcreate -P WorkBenchName
1792 Returns a list of default values for the mandatory parameters to create a workbench.
1794 wcreate MyWorkbench -d
1796 Creates the workbench MyWorkbench using default values for all mandatory parameters.
1797 **Note** The –f option of this command is not obligatory. The system administrator can create the root workbench of a workshop without specifying a parent workbench.
1799 @subsubsection occt_wok_4_7_2 w_info
1801 w_info -option[Workbench]
1802 w_info -option argument[Workbench]
1804 The *w_info* command is the exception to the common command syntax. The form w_info is used instead of winfo because the latter already exists as a tcl/tk command and cannot be reused as a name by WOK. If \<Workbench\> is specified, this determines the workbench to apply to. If no \<Workbench\> is specified, the nearest workbench is used.
1806 Using the tcl winfo command by mistake generates an error message, but does not cause any damage.
1809 * -l - Lists the development units in the workbench.
1810 * -a - Lists the development units in the workbench along with their respective types.
1811 * -f - Displays the parent workbench.
1812 * -A - Lists all the ancestors of the workbench.
1813 * -k - Lists visible toolkits.
1814 * -S \<arg\> - Lists suppliers of the unit \<arg\> within the visibility of the workbench.
1815 * -S <execname:partname> - Lists the suppliers of the component executable partname within an executable development unit execname.
1816 * -I <arg1, arg2 ... argN> - Lists the development units, sorted by order of implementation dependency.
1824 Returns a list of suppliers of the development unit MyDevUnit within the visibility of the current workbench.
1826 @subsubsection occt_wok_4_7_3 wrm
1830 Deletes the workbench, provided that it is empty and has no children. You must not be in a workbench you intend to destroy.
1836 Deletes *MyWorkbench*, provided that it is empty and has no children.
1838 @subsubsection occt_wok_4_7_4 wmove
1839 *Reserved for advanced use*
1840 wmove -f \<NewParentWorkbench\> \<Workbench\>
1841 Moves the \<Workbench\> (and its children), to a different parent *NewParentWorkbench* within the same workshop.
1842 Option -f \<argument\> specifies the new parent workbench.
1847 wmove -f MyOtherWorkbench MyWorkbench
1849 Moves the *MyWorkbench* under *MyOtherWorkbench*.
1851 @subsubsection occt_wok_4_7_5 wprocess
1853 wprocess <WorkbenchName> <options>
1855 Allows automatic reconstruction of a workbench.
1858 * -DGroups =Obj,Lib,Exec - Selects groups Obj, Lib and Exec.
1859 * -DUnits = MyUd1,MyUd2,... - Selects the development units MyUd1, MyUd2 etc.
1860 * -DXGroups =Src,Deliv - Excludes groups Obj and Deliv.
1861 * -DXUnits=MyUd1,MyUd2,... - Excludes units MyUd1, MyUd2 etc.
1862 * -B \<Profile\> - Selects the extraction profile.
1863 * -f - Forces all selected steps.
1864 * -d | -o - Switches between debug and optimized modes.
1865 * -P - Prints out the selected steps.
1866 * -S - Silent mode (no print of the banner).
1867 * -L - Logs output to MyUD_<step code>. Log in step administration directory. Valid group names are: Src, Xcpp, Obj, Dep, Lib, Exec, Deliv.
1872 wprocess -DGroups=Src,Xcpp,Obj,Lib,Exec
1874 Compiles the whole workbench
1876 @subsection occt_wok_4_8 Services Associated with Development Units
1877 The development unit is the basic building block of development work in the WOK environment. It is the base component of Open CASCADE Technology architecture. For a list of available types of development units refer to the <a href="#occt_wok_2_1">Development Units</a> section. There is a dedicated list of commands for management of development units.
1879 * *ucreate* **Creates** a development unit.
1880 * *uinfo* **Displays** information about the development unit.
1881 * *urm* **Deletes** a development unit.
1882 * *umake* **Builds** a development unit.
1884 @subsubsection occt_wok_4_8_1 ucreate
1886 ucreate [-<TypeCode>] <UnitName>
1889 Creates a development unit named \<UnitName\> of type \<TypeCode\>.
1891 Once the creation is completed, a file containing the parameters of the creation of the development unit is generated in the administration directory of the workbench to which the development unit belongs.
1894 * -p - Creates a development unit of type package. This is the default option. Where no option is specified, a development unit of type package is created.
1895 * -n - Creates a development unit of type nocdlpack.
1896 * -s - Creates a development unit of type schema.
1897 * -t - Creates a development unit of type toolkit.
1898 * -d - Creates a development unit of type delivery.
1899 * -x - Creates a development unit of type executable.
1900 * -f - Creates a development unit of type frontal.
1901 * -r - Creates a development unit of type resource.
1902 * -P - Displays ucreate creation possibilities in format: \<TypeCode\> \<TypeName\>.
1907 ucreate -p MyWorkbench:MyPackage
1909 Creates the development unit *MyPackage* in *MyWorkbench*. The unit is of package type.
1911 @subsubsection occt_wok_4_8_2 uinfo
1914 uinfo -t|c [<UnitPath>]
1915 uinfo -f|F|p [-<FilterOption> [<Type>]]* [<UnitPath>]
1918 Displays details about the development unit. Where no \<UnitPath\> is specified, details of the current unit are displayed. Filter options are available for use in conjunction with the options -f, -F, -p to filter the file list. Combinations of filter options can be used.
1920 Note that the uinfo command is based on the results of construction using umake. As a consequence, the list of files displayed by uinfo is only valid if the construction has completed normally. Similarly, the list of files derived from the CDL is only valid if the CDLs of the unit have been translated successfully.
1923 * -t - Displays the type of the development unit as a string.
1924 * -c - Displays the typecode of the development unit, i.e. a single character, as used by *ucreate* to indicate package (p), schema (s) and so on.
1925 * -f - Displays a list of file names associated with the unit.
1926 * -F - Displays a list of file names associated with the unit, together with their respective types. Types of files include for example: *source*, *library*, *executable*, and *pubinclude*. To display a full list of file types, use the command *ucreate*.
1927 * -p - Displays the full paths of the files associated with the unit.
1929 * -T - \<Type\> Displays files of type \<Type\> only.
1930 * -i - Displays only *independent* files, i.e. files that are not specific to a DBMS, for example sources.
1931 * -s - Displays only station dependent files.
1932 * -b - Displays only DBMS dependent files.
1933 * -B - Displays only files that are dependent on *both *DBMS and Station.
1934 * -l - Displays only files that are local to the workbench.
1935 * -m - Displays only missing files, i.e. files that are listed, but not found.
1936 * -e - Displays only existing files, i.e. files that are listed and found.
1943 Displays the types, paths and names of all files associated with the unit.
1945 uinfo -f -Tpubinclude MyWorkbench:MyUnit
1947 Lists the names of the header files associated with the unit MyUnit which is in MyWorkbench.
1949 @subsubsection occt_wok_4_8_3 urm
1953 Deletes the development unit \<UnitPath\> with its directory structure and its files, even if the unit is referenced by another one.
1957 urm MyWorkBench:MyPack
1959 Deletes the development unit *MyPack* found in *MyWorkBench*.
1961 @subsubsection occt_wok_4_8_4 umake
1963 umake -S [<UnitPath>]
1964 umake [-f][<UnitPath>]
1965 umake [-f]-o<step> [-t<target>]* [-o<step> [-t<target>]*]*[<UnitPath>]
1966 umake [-f][-s <step>] [-e <step>][<UnitPath>]
1969 Builds a development unit. The build process includes compilations, links, and various other actions, which make the development unit usable. The build process is specific for each type of development unit, refer to chapter 3 for details.
1970 The following properties apply:
1971 1. There are steps identified by a keyword.
1972 2. The steps involved and their content depends on the type of development unit being treated.
1973 3. You can ask for single step execution using the -o option.
1974 4. Unless explicitly requested using the –f option, the operations are carried out in those steps where necessary.
1975 5. Only the processed development unit is modified.
1977 Used without any arguments the *umake* command carries out all of the steps appropriate for the development unit to be constructed. Using keywords and arguments you can perform the build process step by step.
1980 * -S - Displays the list of steps.
1981 * -s \<step\> - Starts the build process at the step specified.
1982 * -e \<step\> - Ends the build process at the step specified.
1983 * -o \<step\> - Only executes the step specified.
1984 * -t \<target\> - Specifies the target to build.
1985 * -f - Forces the build process, skipping the verification of dependencies.
1992 Builds the gp package.
1994 @subsubsection occt_wok_4_8_5 Specifying Targets (-t) for umake
1996 The umake command is also used to specify build targets and extract C++ method prototypes. src, xcpp and obj units can be targeted. The syntax is explained below.
1997 For delivery units (for all options apart from *.list) the syntax is as follows:
2000 umake MyDeliv -olib.shared.build -tMyUD.
2005 This target computes a source file list as in the example below:
2012 Extracts C++ header files. For -xcpp.\* (with the exception of \*.fill), the syntax is as follows:
2014 umake -o -xcpp.* -t MyPack_MyClass
2016 You extract the method prototypes using the following command:
2018 umake -o xcpp.template [-t<class>|-t<package>]
2020 This syntax of *umake* command is only used with packages. It extracts the C++ prototypes of the methods of the classes contained in the package.
2021 The generated files are placed in the src directory of the current package. These files always have a .template suffix. With each extraction of a class, these files will contain all the methods of the class.
2022 Prototypes are extracted for:
2023 * Ordinary classes (non-instantiated)
2024 * Generic classes (including nested generic classes)
2026 Classes, which are instantiations of generic classes, are not extracted. Nor are other CDL types (exceptions, alias, etc.) which have no user implementation.
2027 For each class, we extract the prototypes of:
2031 The extracted files are the following:
2032 * for an ordinary class C
2033 + C.cxx.template for the non-inline class methods.
2034 + C.lxx.template for the inline class methods.
2035 * for a generic class G
2036 * G.gxx.template for the non-inline class methods.
2037 * G.lxx.template for the inline class methods.
2038 * for a package method P
2039 * P.cxx.template for the non-inline package methods.
2040 * P.lxx.template for the inline package methods.
2045 Specifying the target, *obj* compiles the object files for one or more files. The syntax for -obj.* is as follows:
2047 umake -o -obj.* -t MyPack_MyClass.cxx
2049 In a package, the following command executes all construction steps up to and including obj, doing for each of them only what is strictly necessary:
2053 The following command will recompile all the primary sources of a package which are out of date:
2058 @subsubsection occt_wok_4_8_6 Customizing umake
2059 You can use three levels of umake customization for a development unit.
2060 * Compiler and link options, EXTERNLIB
2062 * Tcl umake step implementation
2063 These different levels of complexity correspond to the needs of regular users and more advanced users.
2065 #### Modification of Compiler and Link Options and EXTERNLIB
2067 Customization at this level involves setting parameters of existing umake steps using an .edl file. This file is taken into account each time umake is performed. It contains a series of assignments or appended variables used when creating the development unit. These commands can be preceded by instructions dedicated to the preprocessor in order to adjust its behavior within the actual context.
2069 EXTERNLIB uses resources contained in Open CASCADE Technology prerequisites. To avoid referencing the path of these resources more than one time, the user may use the component EXTERNLIB to include these resources automatically via the link. The file contains the name of parameters, which are set independently.
2071 The umake command does not generate actual dependencies. To avoid any cumbersome dependencies, for example, if you do not want the shareable library file for a package but the package enumeration only, use the INTERNLIB component listed in FILES, to get only the given dependencies.
2073 In practice, the generated file, \<myUD\>.ImplDep, in the /drv/adm directory, is copied into INTERNLIB. INTERNLIB contains lines of enumerations, as below:
2079 The example below illustrates how you can modify your WOK compiler options. Refer to *Using EDL to Define WOK Parameters* for an example of how to set link options as well as for more details about available parameters and .edl files.
2081 -- File Name: Kernel_CMPLRS.edl
2082 -- Copyright: Matra Datavision 1996
2083 #---------------------------------
2084 #// First, ensure that we only execute this file once
2085 \@ifnotdefined ( %Kernel_CMPLRS_EDL ) then
2086 \@set %Kernel_CMPLRS_EDL = **;
2087 #// Then set C++ compilation options, based on workstation type:
2088 \@if( %Station == *sil* ) then
2089 \@set %ModeOpt = * *;
2091 \@if( %Station == *ao1* ) then
2092 \@set %ModeOpt = *-g *;
2094 \@if( %Station == *hp* ) then
2095 \@string %CMPLRS_C_Options += * -Aa -D_HPUX_SOURCE +e*;
2100 #### Step Definition
2102 The WOK umake command uses a dependency tree. This dependency tree is a graph that shows the umake steps, their inputs and their dependencies. You use it to perform the build, for example to ensure that only files, which have changed, and the files, which depend on these modified files, are recompiled.
2104 This dependency tree is defined in an .edl file. The steps are listed in an order. Each is assigned a name and has its inputs specified. The output of one or more steps is the input to another step.
2106 The following steps are standard for WOK umakes: src, src.list, exec.comp and exec.link. Any new step that you insert into the tree must be associated with a tcl program, which will be responsible for performing the step. You supply these tcl programs. For more details of tcl programming refer to the examples below and also to the <a href="#occt_wok_8">Tcl Overview</a> section.
2108 The following example defines a umake dependency tree and introduces two new steps: exec.kerobj and exec.core. Each of these steps is then associated with a tcl program.
2110 -- File Name: DCube_WOKSteps.edl
2112 \@ifnotdefined (%DCube_WOKSteps_EDL) then
2113 \@set %DCube_WOKSteps_EDL = **;
2114 \@string %WOKSteps_ObjGroup += *obj.libs obj.arx obj.objs *;
2115 ---\@set %WOKUmake_Steps =**src obj.inc(src) objc.cgen(src) obj.comp(src, obj.cgen) obj.libs(src) obj.arx(obj.libs) obj.objs(obj.arx) obj.lib(obj.comp, obj.objs) obj.idep(obj.comp,src)*;
2116 \@set %WOKSteps_obj_libs = *DCube_Libs(src)*;
2117 \@set %WOKSteps_obj_arx = *WOKStep_LibExtract(obj.libs)*;
2118 \@set %WOKSteps_obj_objs = *DCube_Objs(obj.arx)*;
2119 \@set %WOKSteps_obj_lib = *WOKStep_DynamicLibrary(obj.comp, obj.objs)*;
2120 \@set %WOKSteps_toolkit_ListWith = *obj.comp obj.objs*;
2124 #### Tcl Step Implementation
2126 Customization at the tcl step level requires an understanding of the build process and the WOK dependency tree. Modification at this level is generally used to add elements to the build which are not described in the CDL. For example one possible use is to include external libraries or files into the final shareable library. Refer to <a href="#occt_wok_8_3_4">Writing Tcl Steps for a WOK Build</a> for more details.
2128 @subsection occt_wok_4_9 Source Management Services
2129 You use the source management services to integrate source files between a root workbench and one of its children. The services are related to a particular workshop.
2131 * *wprepare* - displays a report of the files state in the current workbench (as compared with the files in the root workbench).
2132 * *wstore* - queues a report for further integration and stores the related files.
2133 * *wintegre* - performs check-in operations for requested files and updates the root workbench.
2134 * *wnews* - allows management and use of data stored in the integration journal.
2135 * *wget* - imports source files to the current workbench.
2137 @subsubsection occt_wok_4_9_1 wprepare
2139 wprepare –wb <father workbench> [-ud <ud1,ud2,...,udN>] -o [<filename>]
2140 wprepare –wb <father workbench> [-ref][-ud <ud1,ud2,...,udN>] -o [<filename>]
2142 Prepares a report for integration to a reference (root) Workbench. This command prints a comparison of the state of source files contained in the specified units, <ud1,ud2,...,udN,> of the current workbench.
2144 This workbench must be a direct descendant of the root workbench. If no unit names are specified, all the units in the workbench are processed. By default, the results of the comparison are printed to the standard output. The differences are computed in relation to the root workbench.
2146 For each file, the status is indicated as follows:
2147 * \# The file has been modified.
2148 * \= The file was found in the current workbench but was not modified.
2149 * \- The file has been removed. In other words, the entry was deleted from FILES).
2150 * \+ The file has been added. In other words, the entry has been added in FILES).
2153 * -ref - Creates a report that is used to initialize a base of source files. This report is used with the *wintegre -ref* command.
2154 * -ud \<ud1\>, \<ud2\>, ..., \<udN\> - Specifies the list of development units to prepare for integration. Separate the unit names with a comma. If no unit names are specified, all the units in the workbench are processed.
2155 * -o \<fileName\> - Writes the integration report to the specified file. By default, the report is displayed (i.e. written to standard output).
2156 * -wb \<The name of target workbench\> - Specifies the name of target workbench. It should be one of father workbenches with attached integration queue.
2158 @subsubsection occt_wok_4_9_2 wstore
2160 wstore –ls –wb <MasterWb>
2162 wstore [-trig] -rm <ID> [-f] –wb <MasterWb>
2163 wstore –create –wb <MasterWb>
2166 This command manages the queue of pending reports. When a report is queued it is given a unique number also called a report-ID.
2169 * \<FileName\> - Adds a report from the file FileName to the report queue.
2170 * -trig - Calls a tcl procedure after the report has been processed. This tcl procedure must be located in the admin directory of the workshop and the file must be named wstore_trigger.tcl. An example of a trigger can be found in the file <i>$env(WOK_LIBRARY)/wstore_trigger.example</i>.
2171 * -ls - Lists pending reports, together with their owners and their IDs. This is a default option. If two files are found with the same name in the same development unit in two different reports the full path of each of these files is displayed.
2172 * -cat \<Report_ID\> - Displays the contents of the report <i>\<Report_ID\></i>.
2173 * -rm - Removes a report from the report queue.
2174 * -f - Forces deletion. This option must be used with the -rm option when you delete a report that you do not own.
2175 * -param - Lists queue parameters associated with the workbench.
2176 * -create –wb \<MasterWb\> -queue \<any/dir\> -type SCCS - Creates an integration queue associated with MasterWb workbench, queue should be located at any/dir and specify SCCS type of database.
2178 Possible options for –create are:
2179 * -queue - Specify the name of directory under which queue is created
2180 * -type - Specify the type of database (can be SCCS or RSC, SCCS by default)
2181 * -base - Specify the location where to put the repository (only for SCCS database). Default behavior: creates repository in the adm directory of the master workbench.
2182 * -counter - Specify the name of directory where the integration counter is located. Default behavior: creates subdirectory adm in directory created using –base option
2183 * -journal - Specify the location of integration journal. Default behavior: : creates subdirectory adm in directory created using –base option
2184 * -welcome - If increment contains new development units, by default store will refuse such increment. If you want to be able to add new units to MasterWb through integration mechanism use – welcome option.
2189 wstore ReportName –wb MasterWb
2191 Queues the report ReportName and saves a copy of the files mentioned in the report. This copy will be used when the report is actually processed by the command *wintegre*.
2193 wstore –wb MasterWb -f -rm Report_ID
2195 Removes the report Report_ID from the queue, even if you do not own it.
2197 @subsubsection occt_wok_4_9_3 wintegre
2199 wintegre [<reportID>] –wb <MasterWb>
2201 Processes a report and removes it from the queue in the current workshop.
2204 * \<reportID\> - Number indicating the rank of the report in the integration queue. Use the command *wstore –l* to get this number.
2207 * -ref \<BaseNumber\> - Initializes the version of the elements in the repository.
2208 * -all - Processes all the reports in the integration queue.
2209 * -wb - Specify the integration queue of which workbench should be used
2210 * -norefcopy - Updates the repository but not the target workbench.
2211 * -nobase - Updates the target workbench but not the repository. This option is rather useful when copying a set of UDs from a workbench into another.
2212 * -param - Shows the parameters’ current value.
2214 **Note** that the -nobase and -norefcopy options are mutually exclusive.
2219 wintegre -ref 2 1 –wb ref
2221 Uses the report whose ID is 1 to initialize the ref workbench with BaseNumber equal to 2.
2225 Integrates the report whose ID is 1 to ref workbench.
2227 wintegre -f 8 –wb ref
2229 Forces the integration of report 8. Use the –f option if you want report 8 to be processed first.
2233 wprepare -MyWb -o/tmp/MyReport
2234 wstore /tmp/MyReport (GetID say 3) –wb ref
2235 wintegre –wb ref -nobase 3
2237 Edit the comment and modify <i>/tmp/MyReport</i> if required with current workbench accessed from ref workbench.
2238 You may use the -nobase option adding the following line in the VC.edl file (Adm of the concerned file):
2240 \@set %VC_TYPE = *NOBASE*;
2242 @subsubsection occt_wok_4_9_4 wnews
2244 The command has the following syntax:
2246 wnews [-x] [-from p1 -to p2] [-headers|-units|-comments|- all] [-command TclCmd]
2247 wnews -set markname [ -at p ]
2254 The *wnews* command allows managing and using the data stored in the integration journal.
2255 The integration journal is updated via the command *wintegre* each time an integration is performed; it contains all the UDs and files concerned with the integration, as well as the comments provided by the developers (reports).
2257 Every integration is numbered and the associated files are archived with a specific version number.
2258 Marks can be set on specific zones of the integrations via the wnews command. A mark is a character string which does not contain any dash character (-) and is associated with an integration number. Several marks may point to the same number, but one mark may only point to one number.
2260 **Note** that *BEGIN* and *END* are reserved mark names. You cannot use them.
2263 * -from p1 -to p2 - Extracts a portion of the journal file between index p1 and p2, with p1 and p2 integration numbers or marks. If p1 is not specified, reports are extracted from the beginning of the journal file. If p2 is not specified, reports are extracted up to the end of the journal file.
2264 * -at p - Places a mark at index p, with p being an integration number. If p is not specified, the mark is placed at the end of the journal.
2265 * -ls [-bydate] - Lists the marks. If -bydate is specified, the marks are listed in the order they were created. Otherwise, they are listed according to their place in the journal file.
2266 * -rm \<markname\> - Removes the mark *markname*.
2267 * -admin - Displays the journal location, date and other information.
2268 * -purge - Saves the journal file and creates a new empty one.
2271 * -o file \<name\> - Redirects output in file. This option is ignored if -command is specified.
2272 * -ws \<shop\> - Uses journal of shop instead of the current one. shop must belong to the current factory.
2273 * -command \<MyCommand\> - Runs the command *Tcl MyComm* on the specified part of the journal. The syntax is the following: *proc MyComm { comments table args } { ...}*, where *comments* is a string containing all the comments on the integration between n1 and n2, and *table* is a table indexed with the names of the concerned *uds* (each element of the table is a list of UD files with definition of their status and version). Additional arguments may be passed using *userdata* with the argument *args* containing *mydata1, mydata2*.
2275 Wok provides a similar procedure *wnews:cpwb*, which allows to copy UDs from one workbench into another.
2277 **Note** that you may access the associated code of this command by typing *tclsh>cat $env(WOK_LIBRARY)/news_cpwb.tcl*
2279 For example, we can add the following to the file *Me.tcl*:
2281 proc MyComm {comments table args} {
2282 puts *comments = $comments*
2288 Then type the following commands:
2291 \> wnews -x -from n1 -to n2 -command MyComm -userdata wb1 wb2
2297 wnews -set BETA_V1.1 -at 345
2299 Sets a mark on integration number 345
2301 wnews -set RELEASED_V1.1_CLOSED
2303 Sets a mark after the last integration performed
2307 Lists all the marks set in the journal
2309 wnews -x -from INT_DEB -to INT_END -units
2311 Gets all the UDs modified between integrations INT_DEB and INT_END. Integration numbers and marks may be mixed as in the following:
2313 wnews -x -from INT_DEB -to 856 -comments
2314 wnews -x -from INT_DEB -to INT_END -comments
2316 Gets all the comments from the integrations between *INT_DEB* and *INT_END*
2318 source Mycommand.tcl
2319 wnews -x -from INT_DEB -to INT_END -command Mycommand
2321 In a more elaborate way, a Tcl process may be called to get all information on the reports between *INT_DEB* and *INT_END*.
2323 wnews -x -from n1 -to n2 -command wnews:cpwb –userdata w1,w2,[ulist, notes]
2325 All modified files between n1 and n2 are copied from workbench w1 into workbench w2. New UDs are created in w2 if required If *ulist* is specified, only the UDs contained in this list are Processed. If notes is specified, all comments between n1 and n2 are written into this file.
2327 @subsubsection occt_wok_4_9_5 wget
2329 wget [-l] –wh <MasterWb>
2330 wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile> [-v <Version>]
2331 wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile1>...<SourceFileN>
2333 The *wget* command allows importing source files into the workbench. The files are fetched from the SCCS database of the factory. This operation is known as a check-out operation. You can specify one or more files or a unit name. By default, the latest version of the files is fetched.
2336 * \<SourceFile\> - Fetches a copy of the specified file.
2337 * -ud \<UnitName\> Fetches all the source files of the development unit you specified.
2338 * -f Forces existing files to be overwritten.
2339 * -v \<Version\> Fetches \<Version\> of the file you specified.
2340 * -l Lists the files of the development unit that can be copied (i.e. that you can **get**). This is a default option.
2345 wget –wb MasteWb –ud MyUd File1.cxx File2.hxx
2347 Fetches the latest version of *File1.cxx* and *File2.hxx*.
2349 @subsubsection occt_wok_4_9_6 Installation Procedure
2351 In the new WOK model:
2352 * each workbench can have its own database
2353 * the version control environment variables are relative to the workbench.
2354 @image html /dev_guides/wok/images/wok_image014.png "Workshop Installation Model"
2355 @image latex /dev_guides/wok/images/wok_image014.png "Workshop Installation Model"
2357 The following procedure explains how to set up the source management environment for a workshop.
2358 1. Open the factory and the workshop.
2360 \> wokcd <factory:workshop> -P Adm
2362 2. Define the environment variables for version control by editing the file *VC.edl*. Your entries should respect the following syntax:
2364 \@set %VC_TYPE=”SCCS”
2365 \@set %VC_ROOT=”/dirA/dirB/.../<MyDir>”
2367 3. Reopen the workbench that you want to connect to the database.
2369 \> wokcd <factory:workshop:workbench>
2371 4. Create SCCS database associated with workbench.
2373 \> wstore –create –wb <factory:workshop:workbench> -queue <PathToQueue>
2375 5. Create a report associated with the root workbench.
2377 \> wprepare –wb <workbench> -o ref.report
2379 6. Queue this report.
2381 \> wstore –wb <workbench> ref.report
2383 7. Perform the actual creation of the SCCS database.
2385 > wintegre –wb <workbench> < BaseNumber >
2387 Here \<BaseNumber\> is the first digit of the SCCS version numbers.
2389 @subsubsection occt_wok_4_9_7 Integration Procedure
2391 To integrate, proceed as follows:
2392 1. Create the report for the current workbench.
2394 \> wprepare –wb MasterWb -o MyReport
2396 2. If necessary, edit this report to remove lines and append comments. Comments should begin with -- (double hyphen).
2397 3. Queue the report and store the files.
2399 \> wstore –wb MasterWb MyReport
2401 By this step, all the files you have modified have been stored and the report has been queued. You can continue with modifying these files.
2403 4. Examine the state of the integration queue to get the ID of your report.
2405 \> wstore –wb MasterWb -ls
2407 5. Perform the integration and be sure you can write in the root workbench. This operation is usually reserved for the workshop administrator.
2409 \> wintegre –wb MasterWb [ID]
2412 @subsection occt_wok_4_10 Session Services
2414 A single session service is also available to allow you to query WOK.
2415 *Sinfo* command returns details of the WOK session.
2421 * -F Gets factory list
2422 * -f Gets current factory
2423 * -s Gets current workshop
2424 * -w Gets current workbench
2425 * -u Gets current development unit
2426 * -t \<entity_path\> Gets the entity type
2427 * -E Reserved for internal use. Gets known Entity List
2428 * -N Reserved for internal use. Gets known Entity Names
2435 Returns a list of WOK factories.
2437 @subsubsection occt_wok_4_10_2 Convenience Aliases
2439 To ease the upgrade to the new version of WOK a number of aliases, compatible with the old version, have been set up. These convenience aliases include:
2440 * **fcd** - Moves to the specified factory.
2441 * **scd** - Moves to the specified workshop.
2442 * **wcd** - Moves to the *src* directory of the specified development unit.
2443 * **wdrv** - Moves to the *drv/DBMS/Station* directory of the current development unit.
2444 * **wls** - Lists the development units in the current workbench.
2445 * **wsrc** - Moves to the *src* directory of the current development unit.
2447 @section occt_wok_5 Using the Graphic Interface
2448 The following is an overall description of the IWOK main menu bar. Please, refer to the on-line help to get more detailed information on the various applications accessed via the graphic interface.
2449 @subsection occt_wok_5_1 Main menu bar
2450 @image html /dev_guides/wok/images/wok_image015.png
2451 @image latex /dev_guides/wok/images/wok_image015.png
2452 @subsubsection occt_wok_5_1_1 Menus
2453 The main menu bar contains three menus:
2454 * **File** to exit the iwok session,
2455 * **Windows** to display all windows created in the session,
2456 * **Help** to display the associated on-line help.
2458 @subsubsection occt_wok_5_1_2 Application icons
2460 The four icons on the left are used to access applications:
2461 * **wprepare**, allows preparing the integration queue being associated with a given workshop,
2462 @image html /dev_guides/wok/images/wok_image016.png
2463 @image latex /dev_guides/wok/images/wok_image016.png
2464 * **umake**, gives access to all available umake options plus compilation options,
2465 @image html /dev_guides/wok/images/wok_image017.png
2466 @image latex /dev_guides/wok/images/wok_image017.png
2467 * **CDL browser**, provides information on the class structure or translated classes,
2468 @image html /dev_guides/wok/images/wok_image018.png
2469 @image latex /dev_guides/wok/images/wok_image018.png
2471 * **parameters**, allows displaying and editing all EDL files.
2472 @image html /dev_guides/wok/images/wok_image019.png
2473 @image latex /dev_guides/wok/images/wok_image019.png
2476 **Note:** for further information on CDL, refer to the CDL Reference Manual.
2478 @subsubsection occt_wok_5_1_3 Display management
2479 Click on the logo to either display or not the session in a window just below the main menu bar.
2481 You may choose to display icons in the window, either in **columns**, with the **last modified first**, by **date and size**, or in **rows**.
2483 Use the **go up** icon to navigate through the session and **wokcd** to update the window where the session was started.
2484 @image html /dev_guides/wok/images/wok_image020.png
2485 @image latex /dev_guides/wok/images/wok_image020.png
2487 The field **Location** gives the exact address of the item in the session. Use the arrow on the right to select already visited addresses.
2489 @subsection occt_wok_5_2 Popup menus
2491 Two types of popup menus may be accessed according to the context. Just click MB3 to display the popup menu.
2493 Click on an item in the left window to get the popup menu providing access to applications.
2495 @image html /dev_guides/wok/images/wok_image021.png
2496 @image latex /dev_guides/wok/images/wok_image021.png
2498 In the right window you get the selection popup menu for the item types:
2500 @image html /dev_guides/wok/images/wok_image022.png
2501 @image latex /dev_guides/wok/images/wok_image022.png
2503 @section occt_wok_6 Appendix A. Using the Emacs Editor
2505 WOK is operated using the editor Emacs. Emacs is not provided in the Open CASCADE Technology distribution but is available from http://www.gnu.org/software/emacs/#Releases
2507 A CDL mode has been created for Emacs. The .el file for this mode is not provided in the distribution, but is available on request from OPEN CASCADE.
2509 List of Keys and their Bindings in cdl Mode
2510 -------------------------------------------
2512 |C-c |Command prefix |
2514 |DEL | backward-delete-character-untabify |
2515 |ESC | Command prefix |
2516 |C-c C-x | cdl-new-exception |
2517 |C-c C-e | cdl-new-enumeration |
2518 |C-c C-b | cdl-new-buffer |
2519 |C-c C-p | cdl-new-package |
2520 |C-c C-r | cdl-new-rubric |
2521 |C-c C-c | cdl-new-class |
2522 |C-c f | cdl-fill-mode |
2523 |C-c s | cdl-structure |
2524 |C-c t | cdl-tabsize |
2525 |C-c e | cdl-comment-end |
2526 |ESC k | cdl-find-class |
2527 |ESC q | cdl-comment-fill |
2528 |ESC TAB | cdl-untab |
2529 |ESC-RET | cdl-raw-newline |
2531 @section occt_wok_7 Appendix B. Parameters and EDL Files
2533 @subsection occt_wok_7_1 EDL language
2535 @subsubsection occt_wok_7_1_1 Key Concepts
2537 EDL is a script-like programming language.
2539 **Comment** - text, preceded by two hyphens.
2543 * **Identifier** - any combination of characters in the ranges A-Z, az, 0-9 and _ (underscore).
2544 * **Variable** - an identifier preceded by % (percent sign).
2545 * **Actions** The following actions are available:
2551 * **Execution** <i>\@uses</i> is an execution operator.
2552 * **Input/Output** The following input/output operators are provided:
2559 * **Conditional Operators** The following conditional operators are provided:
2571 * **Operators** The following operators are available:
2583 **Templates** The following template commands/keywords are available:
2591 **Miscellaneous** The following miscellaneous commands exist:
2597 @subsubsection occt_wok_7_1_2 Syntax
2599 The following conventions are used in the explanations below:
2601 | *\<Variable\>* | refers to a variable, for example: *%myvariable* |
2602 | *\<Id\>* | refers to an identifier, for example: *myidentifier* |
2603 | *“String”* | refers to a string of characters, for example: *“my string of characters”* |
2604 | *\<Condition\>* | refers to a condition, for example: *(%mytest == “ok”) || (%mytest == “good”)* |
2605 | *\<Template\>* | refers to the name of a template, for example: mytemplate. |
2606 |{} | indicates possible repetition of what is within the curly brackets. |
2608 @subsubsection occt_wok_7_1_3 EDL Actions
2613 \@string <Variable> = {<Variable> or “String”} ;
2614 \@string <Variable> += {<Variable> or “String”} ;
2616 Concatenates the contents of the variables and strings on the right of the equals sign and assigns the result to the variable situated on the left. Using the operator ‘+=’ instead of ‘=’ adds the concatenation to the current contents of the variable on the left.
2621 \@set <Variable> = “ String” ;
2623 Sets \<Variable\> to the value “String”
2628 \@apply <Variable> = <Template> ;
2630 Evaluates the template, \<Template\>, and sets \<Variable\> equal to this.
2638 Runs an EDL file. The name of this file is either contained in the variable \<Variable\> or is given as a string, \<String\>.
2643 \@file <Id> <Variable> ;
2644 \@file <Id> “String” ;
2646 Opens a file and associates it with the identifier \<Id\>. This \<Id\> identifies the file until it is closed. The name of the file is given as a string \<String\>, or using a variable \<Variable\>.
2651 \@write <Id> <Variable> ;
2653 Writes the contents of the variable out to a file indicated by the file \<Id\>. This \<Id\> is the identifier allocated to the file when is opened using \@file.
2660 Closes the file identified by \<Id\>. This \<Id\> is the identifier allocated to the file when is opened using \@file.
2665 \@cout {<Variable> or “String”} ;
2667 Concatenates the contents of the variables and strings and displays the result on standard out.
2672 \@iffile ( <Variable> or “String”) then
2674 \@iffile ( <Variable> or “String”) then
2678 Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable \<Variable\>.
2679 If the file exists, the instructions contained in the ‘then’ loop are executed up to the *\@endif*, (or an \@else if one is found before the \@endif ).
2680 If the files do not exist, the ‘else’ loop is executed (if one exists).
2685 \@ifnotfile ( <Variable> or “String”) then
2687 \@ifnotfile ( <Variable> or “String”) then
2691 Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable \<Variable\>.
2692 If the file does not exist, the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
2693 If the file does exist, the ‘else’ loop is executed (if one exists).
2698 \@ifnotdefined ( <Variable> or <Template>) then
2700 \@ifnotdefined ( <Variable> or <Template>) then
2704 Checks for the existence of a variable or template, the name of which is given by \<Template\>, or else contained in the variable \<Variable\>.
2705 If a variable or a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
2706 If neither a variable nor a template exists, the ‘else’ loop is executed (if one exists).
2712 \@ifnotdefined ( <Variable> or <Template>) then
2714 \@ifnotdefined ( <Variable> or <Template>) then
2718 Checks for the existence of a variable or template, the name of which is given by \<Template\>, or else contained in the variable \<Variable\>.
2719 If neither a variable nor a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
2720 If a variable or a template does exist, the ‘else’ loop is executed (if one exists).
2725 \@if (<Condition>) then
2727 \@if (<Condition>) then
2732 If the condition is true the instructions in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
2733 If the condition is false, the ‘else’ loop is executed (if one exists).
2738 \@template <Template> (<Variable>, ... , <Variable>) is
2745 Creates a template, which is a definition that contains variables. The variables on which a template relies are given in parentheses, following the name of the template. These variables are used to evaluate the template, and are referred to as ‘variables of evaluation’. When a template is evaluated (see \@apply) the variables in its definition are replaced by the current values of the ‘variables of evaluation’.
2746 A template is re-evaluated each time it is used.
2751 \@addtotemplate <Template> is
2759 Adds the specified lines to an existing template.
2764 \@cleartemplate <Template> ;
2766 Removes all the lines of a template.
2773 Turns on the verbose mode, such that lines of text are displayed on standard out when you run EDL files.
2780 Turns off the verbose mode, such that lines of text are not displayed on standard out when you run EDL files.
2782 @subsubsection occt_wok_7_1_4 EDL Conditions
2783 Conditions are used with *\@if* commands. Complex and simple conditions are available. The syntax is similar to C++.
2785 #### Simple Conditions
2786 Simple conditions test for equality, the existence of a particular file and so on. The general format is:
2788 \@if(<Condition>) then
2791 The syntax of simple conditions is given below.
2793 <Variable> == “String” -- (equals)
2794 <Variable> != “String” -- (does not equal)
2795 defined(<Variable>) -- (see \@ifdefined)
2796 defined(<Template>) -- (see \@ifdefined)
2797 notdefined(<Variable>) -- (see \@ifnotdefined)
2798 notdefined(<Template>) -- (see \@ifnotdefined)
2799 file(<Variable>) -- (see \@iffile)
2800 file(“String”) -- (see \@iffile)
2801 notfile(<Variable>) -- (see \@ifnotfile)
2802 notfile(“String”) -- (see \@ifnotfile)
2805 #### Complex conditions
2808 Complex conditions take into account the results of other conditions. Complex conditions use the operators || (logical OR) or the operator (logical AND). There are no restrictions on the formulation of these conditions:
2809 * (Simple condition) operator (Simple condition)
2810 * (Complex condition) operator (Simple condition)
2811 * (Simple condition) operator (Complex condition)
2812 * (Complex condition) operator (Complex condition)
2816 \@if ((%a == “0” && %b == “1” && %c == “1”) || %d == “1” && ((%a == “1”) && %b == “1”)) then
2817 \@cout “CONDITION TRUE”;
2819 \@cout “CONDITION FALSE”;
2823 @subsection occt_wok_7_2 WOK Parameters
2824 WOK parameters are defined using EDL. There are two types of EDL parameters: Variables and Templates.
2826 Variables have a ‘fixed’ value. By contrast a template relies on the values of other variables, and must re-evaluate itself each time it is used.
2828 @subsubsection occt_wok_7_2_1 Classes of WOK Parameters
2829 WOK parameters are grouped according to their class. The following classes exist:
2830 | CODEGEN | Code generator options, for example options for lex and yacc. |
2831 | CMPLRS | Compiler options. |
2832 | LDAR | Archive creation options. |
2833 | ARX | Archive extraction options. |
2834 | LDEXE | Executable linker options. |
2835 | LDSHR | Shared linker options. |
2837 @subsubsection occt_wok_7_2_2 Defining WOK Parameters
2838 The WOK distribution includes a base configuration for each class of parameters. This base configuration is provided in the form of EDL files, one file per a class of parameters. Each file is named according to the parameter class:
2840 <ParamClassName>.edl
2842 This configuration file sets the values of all the parameters in the class.
2844 For example, consider a parameter class FOO. There are two variable parameters in this class: FOO_Shared and FOO_Name. These two parameters are assigned a value in the FOO.edl file. The file is given as an example below:
2846 -- standard protection against multiple execution
2847 \@ifnotdefined ( %FOO_EDL) then
2848 \@set %FOO_EDL = **;
2850 -- set %FOO_Shared according to the platform
2851 \@if ( %LocalArch != *hp* ) then
2852 \@set %FOO_Shared = *libCPPExt.so*;
2854 \@if ( %LocalArch == *hp* ) then
2855 \@set %FOO_Shared = *libCPPExt.sl*;
2858 -- set the FOO_Name parameter to FOO
2859 \@set %FOO_Name = *FOO*;
2863 Note that all the parameters in a class take the name of the class as a prefix to their own name. Parameters of type variable are also prefixed by % (percent symbol):
2865 %ClassName_VariableParamName
2866 ClassName_TemplateParamName
2868 A simplified template definition is given as an example below. This definition is based on the FOO parameters set in the previous example above.
2870 Let us define the variable parameter(s) to be used in the template and then the template itself:
2872 \@set %FOO_Shared = *libCPPExt.so*;
2873 \@set %FOO_Name = *FOO*;
2875 \@template FOO_Load ( %FOO_Shared, %FOO_Name) is
2876 $ %FOO_Load_%FOO_Shared %FOO_Name
2880 @subsubsection occt_wok_7_2_3 Redefining Parameters
2881 Occasionally you may want to redefine WOK parameters. For example, you can change the compiler options to force ANSI mode compilation, or redefine how external libraries are referenced.
2882 Before redefining anything, decide on the scope of the redefinition. Is the redefinition to apply to the whole factory, a single workshop, a workbench, or just a development unit? In some cases you may want to redefine parameters within a delivery unit, so that a parcel is delivered with particular options.
2884 The order in which redefinitions are applied (order of precedence) may mean your options are overwritten by subsequent redefinitions.
2886 #### Redefinition Files
2888 Each entity can have an associated redefinition file for each class of parameters. A redefinition file is an EDL file. It always takes the name of the entity to which it belongs, followed by the name of the class of parameters that it applies to:
2890 <EntityName>_<ParamClassName>.edl
2892 For example, the file MyFactory_CMPLRS.edl redefines one of more of the parameters in the CMPLRS class. The scope of this redefinition is MyFactory. To be taken into account by WOK, this redefinition file must be created in the administration directory of the entity to which it belongs. To find out the pathname of this directory, use the command:
2894 wokinfo -p admfile:<EntityName>_<ParamClassName>.edl <EntityPath>
2896 To test whether the file exists actually, use the command:
2898 wokinfo -p adminfile:WOK_LDAR.edl WOK=> /adv22/wok/adm
2900 There is one exception to this rule for file placement. For a development unit, the redefinition file is treated as a *source *file, and consequently it must be located in the src directory of the unit. To find out the path of this directory, use the command:
2902 wokinfo -p source:<UnitName>_<ParamClassName>.edl <UnitPath>
2905 One of the most common reasons to redefine WOK parameters is to modify compiler options. To do this, for example to add a compile option to the package *MyPack*:
2906 * In the source directory of MyPk, create file *MyPk_CMPLRS.edl*
2907 * In this file add the definition:
2909 \@string %CMPLRS_CXX_Options += * -DMyDefine=string *;
2912 Order of Precedence for Parameter Redefinitions
2913 -----------------------------------------------
2914 WOK takes parameter (re)definitions into account in the following order.
2918 * Parcels (within the Workshop configuration, in the order in which they are declared in the parcel configuration).
2919 * Workbench (in order of inheritance)
2921 WOK provides commands to find out what parameter definitions (and redefinitions) are used, and in what order. You can see what compiler parameters are used by WOK in *CMPLRS.edl* file. To find this file, use the command:
2923 wokparam -S CMPLRS.edl
2925 Then run the command.
2927 wokparam -F CMPLRS EntityPath
2929 This command displays a list of all the definition files, for parameters of type compiler, that are taken into account for EntityPath. These file are listed in the order in which they are taken into account. The last definition is the one that is used.
2931 @subsection occt_wok_7_3 Using EDL to Define WOK Parameters
2932 @subsubsection occt_wok_7_3_1 Modification of Link Options - Example
2934 #### How to add a define to the compilation
2936 To add a define for all C++ files compiled in the package *MyPackage*, *MyPackage_CMPLRS.edl* is declared in the development unit *MyPackage* This file contains:
2938 \@string %CMPLRS_CXX_Options =
2939 %CMPLRS_CXX_Options * -DMYDEFINE*;
2942 #### How to use a code generator
2944 In this example, a C code generator is used, which takes the input <i>\<file\>.mygen</i> and generates a <i>\<file\>.c</i>. The step *obj.cgen* automatically recognizes all files with the extension mygen and uses the generator on these files. The resulting .c files are compiled by the step *obj.comp*.
2945 The file *MyUnit_CODEGEN.edl* is written in a nocdlpack development unit *MyUnit*. This file contains the following code:
2948 -- list of tools recognized by the step obj.cgen
2949 -- the tool MYGEN is added
2950 \@ string %CODEGEN_Tools = %CODEGEN_Tools * CODEGEN_MYGEN*;
2952 -- the tool MYGEN is called via the template CODEGEN_MYGEN_CmdLine
2954 \@set %CODEGEN_MYGEN_Template = *CODEGEN_MYGEN_CmdLine*;
2956 -- the extension of files processed by MYGEN is mygen
2958 \@set %CODEGEN_MYGEN_Extensions = *foo.mygen*;
2960 -- the tool MYGEN is the executable /usr/local/bin/mygen
2962 \@set %CODEGEN_MYGEN_Tool = * /usr/local/bin/mygen*;
2964 -- the tool MYGEN produces a .c file
2966 \@template CODEGEN_MYGEN_Production ( %BaseName ) is
2970 -- the command executed to construct the .c file is:
2972 \@template CODEGEN_MYGEN_CmdLine ( %CODEGEN_MYGEN_Tool,
2973 %Source, %BaseName, %OutputDir ) is
2975 $%CODEGEN_MYGEN_Tool -f %Source -o %BaseName.c
2979 @section occt_wok_8 Appendix C. Tcl
2980 @subsection occt_wok_8_1 Tcl Overview
2981 Tcl stands for ‘‘tool command language* and is pronounced ‘‘tickle*. It is actually two things: a language and a library.
2983 As a simple textual language, tcl is intended primarily for issuing commands to interactive programs such as text editors, debuggers, illustrators, and shells. It has a simple syntax and is also programmable, so tcl users can write command procedures to provide more powerful commands than those in the built-in set.
2985 As a library package, tcl can be embedded in application programs. The tcl library consists of a parser for the cl language, routines to implement the tcl builtin commands, and procedures that allow each application to extend tcl with additional commands specific to that application. The application program generates tcl commands and passes them to the tcl parser for execution. Commands may be generated by reading characters from an input source, or by associating command strings with elements of the application's user interface, such as menu entries, buttons, or keystrokes.
2987 For Linux platform it is possible to download Tcltk 8.5 or 8.6 from http://www.tcl.tk/software/tcltk/8.6.html
2988 For Windows platforn it is possible to download ActiveTcl 8.5 or 8.6 from http://www.activestate.com/activetcl/downloads
2990 A help application, tclhelp, is also provided with tcl and can be activated by command *tclhelp*.
2992 @subsection occt_wok_8_2 Tcl and WOK
2993 The tcl interpreter offers WOK the following advantages:
2994 * an environment in which both WOK and UNIX commands are available,
2995 * dynamic loading of WOK as it is needed,
2996 * a high performance portable environment, in which the user can write customized procedures.
2998 The following tcl commands are most commonly used with WOK: *expr, foreach, glob, if, package, proc, puts, set, source* and *unlink*.
3000 Refer to the tcl documentation, or the tcl help application, for details of these and other tcl commands.
3002 @subsection occt_wok_8_3 Configuring Your Account for Tcl and WOK
3003 To have access to WOK you must modify the configuration files of your account as described below.
3004 @subsubsection occt_wok_8_3_1 The cshrc File
3005 To allow the C shell session to configure tcl add the following line to your .chsrc file:
3007 source/<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_TCL
3009 To configure your account to allow access to WOK add the following line to your .cshrc file:
3012 setenv WOKHOME /YOURCONTAINER/wok-<version of wok>
3013 source /<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_Wok
3015 @subsubsection occt_wok_8_3_2 The tclshrc File
3016 To enable configuration of the tcl interpreter, add the following line to your .tclshrc if it exists (if not create one):
3018 source $env(WOKHOME)/site/tclshrc_Wok
3021 @subsubsection occt_wok_8_3_3 The WOK_SESSIONID Variable
3022 The *WOK_SESSIONID* environment variable ensures that you start a new WOK session in the same state and with the same parameter values as your previous WOK session. This continuity is provided by using the same WOK_SESSIONID. Note that your *WOK_SESSIONID* does not change, unless you change it manually.
3024 Make sure that *WOK_SESSIONID* points to (a subdirectory of) your home directory.
3026 @subsubsection occt_wok_8_3_4 Writing Tcl Steps for a WOK Build
3027 There are three advanced WOK commands available for writing umake steps in tcl:
3030 * *stepaddexecdepitem*
3032 *msgprint [-i|-w|-e|-v|-V Class]* prints a message. The output is directed to a WOK internal process that is in charge of printing messages.
3034 The following options are available:
3035 | -i | Prints an information message. |
3036 | -w | Prints a warning message. |
3037 | -e | Prints an error message. |
3038 | -v | Prints a verbose message. |
3039 | -V\<Class\> | Prints a verbose message for class \<Class\>. |
3040 | -c | Prints context of message, i.e. the procedure that called it. |
3044 msgprint -e -c *CCLKernel_GetObjects\::Execute* *Cannot locate object file : * $file;
3046 Writes an error message, in format:
3048 ERROR: CCLKernel_GetObjects\::Execute - Cannot locate object file : MyFile
3050 *stepoutputadd \<options\> \<OutputFileID\> [\<filepath\>]* adds an output file to the outputs of the step. This file is treated by subsequent steps in the same way as all the other output files of the step. The following options are available:
3052 | -p\<path\> | Specifies the path where the file is located. |
3053 | -L | Output can be located (default). |
3054 | -N | Not a WOK file. Cannot be located. |
3055 | -F | Physical file (i.e. resides on a disk somewhere). |
3056 | -M | File is a member of the unit being built (default). |
3057 | -X | File is not a member of the unit being built. Not a WOK file. Cannot be located. |
3058 | -P | File is produced by this umake step (i.e. WOK can delete it because it will be regenerated). |
3059 | -R | File is not produced by this umake step (i.e. WOK must not delete it because it can not be regenerated).
3060 | -S\<StepID\> | Reserved for advanced use. Specifies stepID. |
3061 | -V | Reserved for advanced use. Virtual ‘file’ (i.e. an MSEntity). This option is used for passing keywords between steps for example. |
3065 stepoutputadd -X -R -N -F /usr/myfiles/res.o -p /usr/myfiles/res.o
3067 Adds the file */usr/myfiles/res.o* to the outputs of this step. Specifies that this file is not a WOK file, cannot be located automatically by WOK, and is not generated by this step. Here the full file path is used as the unique file identifier. This appears to be duplicated when it is also given as the physical location of the file.
3069 *stepaddexecdepitem \<options\> \<InputFileID\> \<OutputFileID\>* adds a dependency between one file and another. Typically when introducing external object libraries the files are set to be dependent on the CDL file. We do this because the CDL file changes rarely, so the external files are not needlessly reprocessed, but they are always included in the final executable. The following options are available:
3071 | -d | Adds a direct dependency (default). |
3072 | -i | Adds an indirect dependency. |
3076 stepaddexecdepitem -d MyInFile MyOutFile
3078 States that the file *MyOutFile* depends directly on the file *MyInFile*.
3080 @subsubsection occt_wok_8_3_5 Components of a Tcl UMake Step
3082 Each tcl umake step has the following components:
3083 * *HandleInputFile* - a filter: for each input file this component decides whether or not to accept the file.
3084 * *OutputDirTypeName* returns one of three strings, according to the dependency of the file:
3085 * *tmpfile* = the file is independent (i.e. dependent only on its source);
3086 * *dbtmpdir* = the file is dependent on the database profile;
3087 * *sttmpdir* = the file is dependent on the station profile.
3088 * *AdmFileType* returns one of three strings, according to the dependency of the file:
3089 * *admfile* = the file is independent (i.e. dependent only on its source);
3090 * *Dbadmfile* = the file is dependent on the database profile;
3091 * *stadmfile* = the file is dependent on the station profile.
3093 *Execute* processes each input file that is out of date (i.e. has changed since it was last processed, or depends on a file that has changed since it was last processed). Typically this procedure takes the form of a *foreach* loop. Argument: a development unit to process and a list of one or more arguments.
3095 @subsubsection occt_wok_8_3_6 Sample Tcl Steps
3100 # CCLKernel_GetObjects.tcl
3101 proc CCLKernel_GetObjects::AdmFileType {} {
3104 proc CCLKernel_GetObjects::OutputDirTypeName {} {
3107 proc CCLKernel_GetObjects::HandleInputFile { ID } {
3108 scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name
3110 switch [file extension $name] {
3119 proc CCLKernel_GetObjects\::Execute { unit args } {
3120 msgprint -i -c *CCLKernel_GetObjects\::Execute*
3121 *Processing unit : $unit*;
3122 msgprint -i -c *CCLKernel_GetObjects\::Execute*
3124 set inid [lindex $args 0]
3125 foreach file { Frontal_Ccal_Init_Request.o Frontal_Ccal_Send_Request.o \
3126 Frontal_Ccal_sd.o Frontal_Get_Response.o Frontal_Ccal_Connect.o } {
3127 set resid *Frontal:object:$file*
3128 set path [woklocate -p $resid]
3129 if { $path == ** } {
3130 msgprint -e -c *CCLKernel_GetObjects\::Execute*
3131 *Cannot locate object file : * $file;
3134 msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add
3135 object $file at * $path
3136 stepoutputadd -X -R -L -F $resid
3137 stepaddexecdepitem -d $inid $resid
3140 if { [wokparam -e %Station] == *sun* } {
3141 set file *risc_return.o*
3142 set resid *CCLKernel:source:$file*
3143 set path [woklocate -p $resid]
3144 ## set path */adv_23/wb/kl/Kernel7/prod/EngineStarter/
3146 msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add
3147 object $file at * $path
3148 stepoutputadd -X -R -N -F $path -p $path
3149 stepaddexecdepitem -d $inid $path
3151 set home [wokparam -e %Ilog_Home]
3152 if { $home == ** } {
3153 msprint -c *CCLKernel_GetObjects\::Execute* -e *Cannot
3154 evaluate parameter : %Ilog_Home
3157 foreach file { llstdio.o llfloat.o llfloat31.o cfix.o
3158 lelisp.o getgloba.o cload.o } {
3159 set path *$home/o/$file*
3160 msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add
3161 object $file at * $path
3162 stepoutputadd -X -R -N -F $path -p $path
3163 stepaddexecdepitem -d $inid $path
3165 set file *lelisp31bin.o*
3166 set path *$home/lelisp31bin.o*
3167 msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add
3168 object $file at * $path
3169 stepoutputadd -X -R -N -F $path -p $path
3170 stepaddexecdepitem -d $inid $path
3171 if { $failed } {return 1;}
3177 # File Name: CCLKernel_core.tcl
3178 proc CCLKernel_core::AdmFileType {} {
3181 proc CCLKernel_core::OutputDirTypeName {} {
3184 proc CCLKernel_core::HandleInputFile { ID } {
3185 scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name
3198 proc CCLKernel_core\::Execute { unit args } {
3199 global WOK_GLOBALS env
3200 msgprint -i -c *CCLKernel_core\::Execute* *Processing unit : $unit*;
3201 msgprint -i -c *CCLKernel_core\::Execute*
3202 set workbench [wokinfo -N $unit]
3203 set unitname [wokinfo -n $unit]
3210 scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* Unit type name
3214 set lispbin [stepinputinfo -p $ID]
3220 set lispfile [stepinputinfo -p $ID]
3224 if { $lispfile == **} {
3225 set lispfileid *CCLKernel:source:CCL_lelisp.ll*;
3226 set lispfile [woklocate -p $lispfileid $workbench]
3228 if { $lispbin == **} {
3229 msgprint -e -c *CCLKernel_core\::Execute* *Cannot find lelispbin in input*
3232 msgprint -i -c *CCLKernel_core\::Execute* *Using lelisp.bin at * $lispbin
3233 msgprint -i -c *CCLKernel_core\::Execute*
3234 set config *[wokparam -e %Ilog_Home]/config*
3235 set tmpdir [wokinfo -p sttmpdir:. $unit]
3236 set output [wokinfo -p executable:. $unit]
3237 set lelisppointbin [wokinfo -p executable:lelisp.bin $unit]
3238 unlink -nocomplain $lelisppointbin
3239 link -sym $lispbin $lelisppointbin
3240 msgprint -i -c *CCLKernel_core\::Execute* *Setting Environment*
3241 set WOK_GLOBALS(setenv_proc,tcl) 1
3243 set WOK_GLOBALS(setenv_proc,tcl) 0
3245 cd [wokinfo -p source:. $unit]
3246 set FrontSIZE *-stack 12 -code 1500 -heap 2048 -number 0 -vector 32 -string 50 -symbol 30 -float 0 -cons *
3247 msgprint -i -c *CCLKernel_core\::Execute* *Exec : $config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*
3248 puts *exec /bin/env \\
3250 WBPACKAGE=[wokinfo -n $unit] ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
3251 CSF_EngineStarterList=/usr/local/etc/
3252 EngineStarter.Hosts \\
3253 ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
3254 \*FrontSIZE=$FrontSIZE\* \\
3255 $config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*
3256 msgprint -i -c *CCLKernel_core\::Execute* [eval *exec /bin/env \\
3258 WBPACKAGE=[wokinfo -n $unit] \\
3259 ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
3260 CSF_EngineStarterList=/usr/local/etc/ EngineStarter.Hosts \\
3261 \*FrontSIZE=$FrontSIZE\* \\
3262 $config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*]
3263 stepoutputadd -P $unitname:corelisp:$unitname.core
3264 stepaddexecdepitem -d $lispbinid
3265 $unitname:corelisp:$unitname.core
3266 stepaddexecdepitem -d $lispfileid
3267 $unitname:corelisp:$unitname.core