Workshop Organisation Toolkit {#user_guides__wok} ============================== @section occt_wok_1_ Introduction Glossary @subsection occt_wok_1_1 About the Development Environment 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. @subsection occt_wok_1_2 Brief Overview of Open CASCADE Technology Development Environment 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. ![](/user_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform") 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**. 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. @subsection occt_wok_1_3 WOK Components @subsubsection occt_wok_1_3_1 Entities 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 *Glossary* section. @subsubsection occt_wok_1_3_2 Files 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. @subsection occt_wok_1_4 Glossary @subsubsection occt_wok_1_4_1 Development Units A **development unit** is the smallest unit that can be subject to basic development operations such as modifying, compiling, linking and building. 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*. * package (p) A set of related classes and methods along with their CDL definitions. * schema (s) A set of persistent data types. * executable (x) An executable is used for unit and integration test purposes. It is based on one or more packages. * nocdlpack (n) A package without a CDL definition. Used for low-level programming or for incorporating foreign resources. * interface (i) A specific set of services available for wrapping (an interface contains packages, classes, and methods). * jni (j) A development unit used to wrap C++ classes to Java. It is based on one or more interfaces. * toolkit (t) A set of packages. Useful in grouping packages together when there is a large number of packages based around a particular subject. * delivery (d) A development unit for publishing development units. * resource (r) A development unit containing miscellaneous files. @subsubsection occt_wok_1_4_2 Workbenches 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. ![](/user_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units") @subsubsection occt_wok_1_4_3 Workshops 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. The root workbench is in a valid state and contains the working versions of the development units. Development units in a root workbench are visible in its child workbenches. 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 ![](/user_guides/wok/images/wok_image007.png "Workbenches") 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. ![](/user_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels") @subsubsection occt_wok_1_4_4 Factories 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. 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. ![](/user_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse") @section occt_wok_2_ Elements of the Platform @subsection occt_wok_2_1 Development Units A **development unit** is the basic element of WOK development. It includes the following three entities: * A directory structure (a minor component) * Source files, also called primary files * The result of the build process (compilation, etc.), also called derived files. @subsubsection occt_wok_2_1_1 Directory Structure of a Development Unit 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 *Workbenches* section for further details on the workbench structure. @subsubsection occt_wok_2_1_2 Files in a Development Unit Source Files ------------ Source files are written by the developer in the source section (the **src **directory) of the development unit. 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: * 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. * schema (s) No description of the source files is needed. There is a single source file: schema.cdl. * executable (x) The names of all source files are worked out from the CDL description. The format of this file is described in the *Building an Executable* section. * nocdlpack (n) The list of source files is contained in the FILES file stored in the unit’s src directory. interface (i). No description of the source files is needed. There is a single source file: interface.cdl. * jni (j). No description of the source files is needed. There is a single source file: jni.cdl. * 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. * 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. * 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*. Derived files ------------- 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. @subsubsection occt_wok_2_1_3 Package 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. 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. C++ implementation files are also stored in the src subdirectory of the package development unit. These implementation files are: * .cxx for an ordinary class * .lxx for any inline methods * .pxx for any private declarations * .gxx for a generic class To create the Development Unit structure for a package use the following syntax: ~~~~~ ucreate –p MyPackage ~~~~~ The package description has the following CDL syntax: ~~~~~ package PackageName [uses AnotherPackage {‘,’ YetAnotherPackage}] is [{type-declaration}] [{package-method}] end [PackageName]’:’ ~~~~~ For example: ~~~~~ package CycleModel uses Pcollection Tcollection BREpPrimAPI TopExp Geom Pgeom is deferred class Element; class Wheel; class Frame; class LocalReference; Adjust(awheel: wheel from CycleModel;   aframe: Frame from CycleModel); end CycleModel; ~~~~~ For full details on the CDL syntax, refer to the *CDL User’s Guide*. @subsubsection occt_wok_2_1_4 Schema 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**. 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. 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. To create the Development Unit structure for a schema use the syntax below: ~~~~~ ucreate –s MySchema ~~~~~ The schema description has the following CDL syntax : ~~~~~ schema SchemaName is ListOfPackagesContainingPersistentClasses; ListOfPersistentClasses; end; ~~~~~ For example: ~~~~~ schema MyCycleSchema is class Wheel from package CycleModel; class Frame from package CycleModel; .. class Spanner from package CycleTools; end; ~~~~~ For full details on the CDL syntax, refer to the *CDL User’s Guide*. @subsubsection occt_wok_2_1_5 Executable 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. 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. To create the Development Unit structure for an executable, use the syntax below: ~~~~~ ucreate –x MyExec ~~~~~ The executable description has the following CDL syntax: ~~~~~ executable ExecName is executable BinaryFile uses LibFile as external is C++File; end; end; ~~~~~ For example: ~~~~~ executable MyExecUnit’ is executable myexec uses Tcl_Lib as external is myexec; end; executable myex2 is myex2; end; end; ~~~~~ For full details on the CDL syntax, refer to the *CDL Reference Manual*. @subsubsection occt_wok_2_1_6 Toolkit 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: * Linking of large numbers of packages * Faster loading of executable files that use toolkits such as test files. 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. You then compile the toolkit to create a shareable library. @subsubsection occt_wok_2_1_7 Nocdlpack 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. 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. On compilation, the result is a shareable library. @subsubsection occt_wok_2_1_8 Interface An interface is a development unit that defines a set of services available for wrapping into Java. 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. To create the Development Unit structure for an interface, use the syntax below: ~~~~~ ucreate -i MyInterface ~~~~~ The interface description has the following CDL syntax: ~~~~~ interface InterfaceName is ListOfPackages ListOfClasses ListOfMethods end; ~~~~~ For example: ~~~~~ interface MyInterface is         package TopoDS;         class Shape from ShapeFix; end ; ~~~~~ @subsubsection occt_wok_2_1_9 Jni A jni is a development unit that wraps declared services into Java using JNI (Java Native Interface). A jni creates Java classes that are used as C++ counterparts when developing in Java. To create the Development Unit structure for an Jni, use the syntax below: ucreate -j MyJni The interface description has the following CDL syntax: ~~~~~ client JniName is {interface InterfaceName;} end; ~~~~~ For example : ~~~~~ client MyJni is         interface MyInterface;         interface MyAnotherInterface; end ; ~~~~~ @subsubsection occt_wok_2_1_10 Delivering Parcels 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. 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. All Open CASCADE Technology resources are seen as parcels. ![](/user_guides/wok/images/wok_image010.png "Parcels") You create a delivery unit under a specified workbench. 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. **Note** If you do not specify a workbench when you make a delivery, it is created under the current workbench. @subsection occt_wok_2_2 Workbenches 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. @subsubsection occt_wok_2_2_1 Roots The following roots are used in the structure of a workbench: * Home Workbench root containing various administration files of the workbench. * Src Root of the workbench sources, which facilitates the integration into WOK of version management software such as CVS. * DBMS Root of the derived files dependent on the extraction profile (.hxx, _0.cxx files, etc.). * DBMS_Station Roots of the derived files dependent on the extraction profile and on the platform (.o, .so files, etc.). 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: Home Workbench root, Src Root of the source files, DFLT Root of the derived files, DFLT_sun Root of the files built on Sun platforms, DFLT_sil Root of the files built on SGI platforms, For a workbench additionally supporting *ObjectStore*, the following additional roots are also found: *OBJS, OBJS_sun, OBJS_sil*. These roots are defined in the workbench definition file *MyWorkbench.edl* as the parameter *%MyWorkbench_RootName*. **Note** that default values help to define various roots. @subsubsection occt_wok_2_2_2 Directories Under each root, a hierarchy of directories allows to store various files. Under the Home root are found: * work, the private workbench directory reserved for the developer * Adm, the directory reserved for administration files. Src contains: * src/MyUD, the directory containing the source files of the development unit MyUD. DBMS contains: * inc, containing the public header files of the workbench UDs * drv/MyUD, containing the private extracted files of MyUD * drv/MyUD/.adm, containing the administration files dependent on the extraction profile * drv/MyUD/.tmp, containing the temporary files dependent on the extraction profile. DBMS_Station contains: * /lib with all the libraries produced in the workbench * /bin with all the binaries produced in the workbench * /MyUD with all the station dependent files which are private to the development unit such as objects * /MyUD/.adm with all the station dependent administration files * /MyUD/.tmp with all the temporary files constructed in the development unit. ![](/user_guides/wok/images/wok_image011.png "Structure of the workbench *Mywb* ") @subsection occt_wok_2_23 Workshops 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. ![](/user_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop") In this image: * **A** is the development unit A from Grandchild 11 placed in reference in root. It is visible throughout the workshop. * **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. 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. 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. When creating a new workshop, you specify - in the form of parcels – which resources are to be available within the workshop. @subsection occt_wok_2_2_4 Factories 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. There is no theoretical limit to the number of workshops that can be added to a factory. However, a single factory should be enough. @section occt_wok_3 Development Process @subsection occt_wok_3_1 WOK Environment 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. Before you run a tcl session you must make sure that your account is configured for using tcl, see the *Configuring Your Account for Tcl and WOK* section. To start a tcl session use the command: ~~~~~ % tclsh ~~~~~ 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. To exit from a tcl session use the command: ~~~~~ > exit ~~~~~ Online help is provided with tcl. To access this, use the following command: ~~~~~ % tclhelp ~~~~~ 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: ~~~~~ > wokcd -h ~~~~~ @subsection occt_wok_3_2 Steps Implementation of an application is based on the following steps: 1. Enter the software factory using the command wokcd MyFactory 2. Enter a workshop using the command wokcd MyWorkshop 3. Open a workbench using the command wokcd MyWorkbench 4. Search for the data types required among the existing OCCT libraries 5. Define one or more packages which will contain the classes 6. Define new data types as classes 7. Implement the methods of those classes in C++ 8. Implement any package methods in C++ 9. Unite the test packages 10. Define any nocdlpacks (if any) 11. Test the components **Note:** Steps 1-3 can be performed with a single WOK command: ~~~~~ > wokcd MyFactory:MyWorkshop:MyWorkbench ~~~~~ @subsection occt_wok_3_3 Getting Started @subsubsection occt_wok_3_3_1 Entity Names Before you start, the following restrictions on WOK entity names must be noted: * Entity names may only contain alphanumeric characters and dashes. * 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. * 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. * Parcel names must be unique. @subsubsection occt_wok_3_3_2 Entering the Factory When you start work you go to the factory using the following command: ~~~~~ > wokcd ~~~~~ @subsubsection occt_wok_3_3_3 Creating a New Workshop 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: ~~~~~ > screate –d ~~~~~ This creates the new workshop **MyWorkshop** in the current factory. To create the same workshop in a different factory use the syntax below: ~~~~~ > screate –d ~~~~~ When you create a new workshop, it is empty. @subsubsection occt_wok_3_3_4 Selecting Parcels 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: ~~~~~ > screate –d -DparcelConfig=Parcel1,Parcel2… ~~~~~ To display available OCCT resources, in other words, to see what parcels are available, you use the following command: ~~~~~ Winfo –p ~~~~~ **Note:** parcel configuration rarely needs to change. If it does, only the workshop administrator should make them. @subsubsection occt_wok_3_3_5 Opening a Workshop To open a workshop, you use the following command: ~~~~~ > wokcd ~~~~~ @subsubsection occt_wok_3_3_6 Creating a New Workbench When you create a new workshop, it is empty. In other words, it does not contain any workbenches. To create the root workbench of a new workshop, you use the following command: ~~~~~ > wcreate -d ~~~~~ This creates a tree of workbench subdirectories. 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: ~~~~~ > wcreate –d -f ~~~~~ @subsubsection occt_wok_3_3_7 Opening a Workbench To open a workbench, you use the command below: ~~~~~ > wokcd ~~~~~ This automatically takes you to the root directory of the workbench @subsubsection occt_wok_3_3_8 Using Existing Resources 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. @subsection occt_wok_3_4 Creating Software Components @subsubsection occt_wok_3_4_1 Creating a Package To develop new software components, you usually need to create one or more packages. You do this, by using the following command: ~~~~~ > ucreate –p ~~~~~ 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: ~~~~~ > ucreate ~~~~~ Enter a Package or other Development Unit Structure ---------------------------------------------------- Enter the package or any other development unit structure using the *wokcd* command as in the syntax below: ~~~~~ > wokcd MyPackage ~~~~~ The current directory is now: ~~~~~ MyWorkbenchRoot/src/MyPackage ~~~~~ Writing the Package and Class Specifications in CDL --------------------------------------------------- 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. CDL Compilation of the Package ------------------------------ Compile and check the package and its classes using: ~~~~~ > umake –e xcpp ~~~~~ This command also extracts the C++ header files (.hxx) and stores them in the derived files directory. Implementing Methods in C++ --------------------------- A package will contain methods, which may be: * Instance methods * Class methods * Package methods. Extract **prototypes** for the C++ methods using the following command: ~~~~~ > umake -o xcpp.fill -o xcpp.template ~~~~~ You should not confuse this syntax with the template feature of C++ used to implement the genericity. The *umake -o xcpp.template* command creates a skeleton C++ file for: * Each class * All the package methods. The packages methods will be created in a file called package.cxx.template. This command is *not *included in the umbrella command MyPackage. You will need to use an editor to implement these methods in C++. Compiling the Package --------------------- To compile the package, use the command: ~~~~~ > umake -o obj ~~~~~ If you do not specify a package, the current development unit is compiled. Sample Construction of a Package --------------------------------- 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: 1. Create the MyWb workbench as a child of Topo. ~~~~~ > wcreate MyWb -f Topo -d ~~~~~ 2. Create MyPack in MyWb. ~~~~~ > ucreate MyPack     ~~~~~ 3. Move to the source directory of MyPack. ~~~~~ > wokcd MyPack ~~~~~ 4. Edit the source files (MyPack.cdl etc.). You do this outside tcl, using the editor of your choice. 5. Start the extraction of MyPack. ~~~~~  > umake -e xcpp ~~~~~ 6. Generate the .cxx templates for MyPack: MyPack.cxx.template ~~~~~    > umake -o xcpp.fill -o xcpp.template -t ~~~~~ 7. Edit the source files (MyPack.cxx etc). You do this outside tcl, using the editor of your choice. **Note*** *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. Package Files ------------- * Primary Files for a Package + .cdl Primary package file. + _.cdl Primary class file. * C++ Files for a Package + .cxx Primary package source file. + _[1..9[0..9]*].cxx Secondary package source files. + .lxx Inline package methods source file. + .pxx Private instructions source file. * C++ Files for a Class + _.cxx Primary class source file. + __[1..9[0..9]*].cxx * Secondary class source files. + _.gxx Generic class methods source file. This is an alternative to the .cxx file(s), you do not have both. + _.lxx Inline methods source file. + _.pxx Private instructions source file. * Derived C++ Files for a Package + .hxx User header file. + .ixx User header file included in .cxx. + .jxx User header file included in _[1-9].cxx. * Derived C++ files for a class + _.hxx User header file. + _.ixx User header file included in _.cxx. + _.jxx User header file in __[1..9[0..9]*].cxx. + Handle__.hxx Persistent or Transient class header file. + __0.cxx For instantiated classes. Umake Steps for a Package ------------------------- The umake steps for development units of package type are explained below. * 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. * xcpp.fill     Compiles the internal data structure to prepare for subsequent extractions. * xcpp.src    Lists the source files (.cxx, .gxx, .lxx) deduced from the CDL files. * xcpp.header                                   Extracts header files for the classes in the development unit. * xcpp.template (Hidden step.)          Extracts a template for implementation of methods. * 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. * obj.cgen                            Processes the source files to generate code. * obj.comp                           Compiles each file that can be compiled. * obj.idep                             Generates dependency information for the unit. This comprises: + Includes performed by unit compilation (Unit.MakeState) + Implementation dependencies in terms of the unit suppliers (Unit.ImplDep) * obj.lib                                            Generates the shared library for the development unit. @subsubsection occt_wok_3_4_2 Creating a Nocdlpack 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: ~~~~~ > ucreate -n > wokcd ~~~~~ Use an editor to write FILES. This file must list all the C, C++, Fortran, lex, and yacc sources. Build the nocdlpack using the following command: ~~~~~ > umake [] ~~~~~ **Note** that a nocdlpack unit is not intended to perform tests. Use an executable unit instead. *FILES: * Is a nomenclature file for a nocdlpack. It is a list of Fortran, C, C++, lex, and yacc files (one per line). Sample Construction of a Nocdlpack ----------------------------------- In the following example a nocdlpack, MyNocdlpack, is created. Commands preceded by an asterisk below are used only once per session: 1. \*Create MyNocdlpack in MyWb. ~~~~~ > ucreate -n ~~~~~ 2. Move to the source directory of MyNocdlpack. ~~~~~ > wokcd ~~~~~ 3. Write the FILES list. You do this outside tcl, using the editor of your choice. 4. Write the source code. 5. Build MyNocdlpack. ~~~~~ > umake [] ~~~~~ Umake Steps for a Nocdlpack --------------------------- The *umake* steps for development units of nocdlpack type are explained below. * src                         Processes FILES to list source files. * obj.cgen    Processes the source files to generate code. * 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. * obj.comp   Compiles each file that can be compiled. * obj.idep     Generates dependency information for the unit. This comprises: + Includes performed by unit compilation. (Unit.MakeState) + Implementation dependencies in terms of the unit suppliers. (Unit.ImplDep) * obj.lib                    Generates the shared library for the unit. @subsubsection occt_wok_3_3_3 Creating a Schema 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. You create a schema and go to its root directory using the commands: ~~~~~ > ucreate -n > wokcd ~~~~~ 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: ~~~~~ schema MySchema is class from ; end; ~~~~~ Building a Schema ~~~~~~~~~~~~~~~~~ Compile and check the coherence of the CDL specification for the schema: ~~~~~ > umake -e xcpp.fill ~~~~~ Extract the C++ description: ~~~~~ > umake -o xcpp ~~~~~ Compile the C++ description of the schema: ~~~~~ > umake -o obj ~~~~~ Alternatively, the above three steps can all be carried out by one command: ~~~~~ > umake ~~~~~ Sample Construction of a Schema ------------------------------- 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: 1. Create MySchema in MyWb. ~~~~~ > ucreate -s MySchema ~~~~~ 2. Move to the source directory of MySchema. ~~~~~ > wokcd MySchema ~~~~~ 3. Edit the source file MySchema.cdl. You do this outside tcl, using the editor of your choice. 4. Derive implementation files. ~~~~~ > umake -e xcpp.sch ~~~~~ 5. Derive application schema files. ~~~~~ > umake -o xcpp.ossg ~~~~~ 6. Compile the schema. ~~~~~ > umake -o obj ~~~~~ Schema Files ------------ * Primary Files for a Schema + .cdl Primary schema file. * Derived C++ Files for a Schema + .hxx User header files. + .cxx Schema implementation files. + .cxx Schema implementation files. Umake Steps for a Schema ------------------------ The umake steps for development units of schema type are explained below. * src        Processes MySchema.cdl to generate a list of CDL files for the development unit. Processes the FILES file to list source files. * xcpp.fill  Compiles the internal data structure to prepare for subsequent extractions. * xcpp.sch   Extracts the schema implementation code. * obj.comp   Compiles the extracted files that can be compiled. * obj.lib    Generates the shared library for the unit. * obj.idep   Generates dependency information for the schema. @subsection occt_wok_3_5 Building an Executable @subsubsection occt_wok_3_5_1 Creating an Executable 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. Writing an Executable --------------------- Refer to the *CDL User’s Guide *for full details. A simple example is given below. executable // the executable unit is executable myexec // the binary file uses Tcl_Lib as external is myexec; // the C++ file end; // several binaries can be specified in one .cdl file. executable myex2 is myex2; end; end; Write the C++ file(s). For the example above you write the files: myexec.cxx and myex2.cxx. Building the Executable ----------------------- To build the executable, use the command: > umake Construction of an Executable ----------------------------- 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: 1. \*Create MyExec in MyWb. > ucreate -x MyExec 2. Move to the source directory of MyExec. > wokcd MyExec 3. Edit the cdl source file (MyExec.cdl). You do this outside tcl, using the editor of your choice. 4. Edit the C++ files (AnExe.cxx etc.). You do this outside tcl, using the editor of your choice. 5. Build MyExec. > umake 6. Run the executable file. > wokcd -PLib > MyExec Executable Files ---------------- * Primary Files for an Executable + .cdl Primary executable file * C++ Files for an Executable + .cxx Source file + _[1-9].cxx Other source files Umake Steps for an Executable ----------------------------- The umake steps for development units of executable type are explained below. * src Processes MyExe.cdl to generate a list of CDL files for the development unit. Processes FILES to list source files. * src.list Based on MyExe.cdl, works out the list of parts and the source files involved for each part. * exec.comp Compiles the files that can be compiled for each part of the executable. * exec.idep Generates dependency information for each part of the executable. * exec.libs Computes full implementation dependency to prepare for linking for each part of the executable. * exec.tks Performs toolkit substitution according to TOOLKITS for each part of the executable. * exec.link Links each part of the executable. @subsection occt_wok_3_6 Test Environments @subsubsection occt_wok_3_3_1 Testing an Executable To test an executable, you create an executable development unit and move to its structure. See the *Building an Executable* section for details. When you write the .cdl file for your test executable, specify the packages to test, for example: ~~~~~ executable MyTest // the executable unit is executable mytest1 // the binary file is mytest1; //the C++ file end; // several binaries can be specified in one .cdl file. executable mytest2 is mytest2; end; end; ~~~~~ Write the C++ test file(s), in the example, *mytest1.cxx* and *mytest2.cxx*. Building the Executable ----------------------- To build the executable use the command: ~~~~~ > umake ~~~~~ Sample Construction of a Test Executable ---------------------------------------- The overall process of constructing a test executable is the same as for any other executable. For a sample, refer to the *Construction of an Executable* section. Setting up a Test Environment ----------------------------- To set up a test environment, move to the * /drv* subdirectory that corresponds to the current profile (e.g. the directory: * /MyExec/drv/DFLT/sun* directory) and run the executable test file. ~~~~~ > wokcd -PLib > wokenv -s > myApp ~~~~~ The command *wokenv* is used with -s option to configure the test environment. 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. WOK sets the following environment variables: * *$STATION* - The current station. * *$TARGET_DBMS* - The current database platform. * *$PATH* - The current path, plus the bin directories of the parcels. * *$LD_LIBRARY_PATH* The current path, plus the lib directories of the parcels. 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*. *$ORIGDELIVUNITHOME* is set as the root directory of the parcel. WOK then sources the following files: * MyFactory.tcl, found in the admin directory of the factory. * MyWorkshop.tcl found in the admin directory of the workshop. Then for each Workbench, WOK sources according to the hierarchy of the workbenches: * Workbench.tcl, found in the /Adm directory of the workbench. After the environment is set up, you are at a C shell prompt and can run the executable. **Note** Environment variables are only set when the command is used with the option *-s*. 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. 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. To create the script file use the following command: ~~~~~ > wokenv -f -t csh ~~~~~ This commands generates a file, ScriptFile, which configures a C shell to mirror the current WOK environment. An example script file is given below. ~~~~~ setenv STATION *sil* setenv TARGET_DBMS *DFLT* setenv KERNELHOME */adv_22/WOK/BAG/KERNEL-K1-2-WOK* setenv LD_LIBRARY_PATH */adv_22/WOK/BAG/wok-K1-2/lib/sil:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/lib/* 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/* source /adv_22/WOK/BAG/KERNEL-K1-2-WOK/adm/Kernel.csh ~~~~~ @subsection occt_wok_3_7 Building a Toolkit @subsubsection occt_wok_3_7_1 Creating a Toolkit You create and enter a toolkit development unit using the following commands: ~~~~~ > ucreate -t > wokcd ~~~~~ Write the Nomenclature File for the Toolkit ------------------------------------------- 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. Build the shareable library for this toolkit as follows: ~~~~~ > umake [] ~~~~~ **Note:** when one of the packages in the toolkit is modified, recompile the toolkit. A package should belong to one toolkit only. Sample Construction of a Toolkit -------------------------------- In the following example, the toolkit **TKMyToolkit** is created. Commands preceded by an asterisk below are used only once per session: 1. \*Create MyToolkit in MyWb. ~~~~~ > ucreate -t TKMyToolkit ~~~~~ 2. Move to the source directory of MyToolkit. ~~~~~ > wokcd TKMyToolkit ~~~~~ 3. Edit the nomenclature files, PACKAGES and FILES. You do this outside tcl, using the editor of your choice. 4. \*Create the library for MyToolkit ~~~~~ > umake TKMyToolkit ~~~~~ Umake Steps for a Toolkit ------------------------- The umake steps for development units of toolkit type are explained below. * src Processes FILES to list source files. * lib.list Works out the objects and archive library to add to the toolkit shared library. * lib.limit Manages the build process strategy within the limitations of a particular platform. * lib.arch Builds archives according to the building strategy. * lib.uncomp Decompresses third party archives. * lib.arx Extracts object files from archives. * lib.build Generates the shared library for the toolkit. Building strategy depends on the platform. The following step sequences apply: * On Sun (Solaris): ~~~~~ src lib.list lib.arx lib.build ~~~~~ * On sil (IRIX): ~~~~~ src lib.list lib.uncomp lib.build ~~~~~ The TOOLKITS File ----------------- 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: No TOOLKITS file found: All toolkits are candidates for substitution. To find out which toolkits are candidates, use the command *w_info -k*. Empty TOOLKITS file found: No toolkit is a candidate for substitution. Non-empty TOOLKITS file found: Only those toolkits listed in the TOOLKITS file are candidates for substitution. Toolkit Substitution -------------------- Toolkit substitution is performed as follows: MyEngine uses: A, B and C The toolkit TK provides: A and D D uses: E Compilation of *MyEngine* includes: TK, B C and E Here, for simplicity, assume that additional toolkits are not substituted for B, C and E. @subsection occt_wok_3_8 Building a Delivery Unit @subsubsection occt_wok_3_8_1 Creating a Delivery Unit > ucreate -d Writing the COMPONENTS File --------------------------- 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. Note that keywords and default options are shown in bold. ~~~~~ **Name** ParcelName Put path Put include Put lib **Requires** DeliveryName\* **Package** MyPack **[CDL][LIBRARY][INCLUDES][SOURCES]** **Nocdlpack** MyNcdl **[LIBRARY][INCLUDES][SOURCES]** **Executable** MyExec **[CDL][DYNAMIC][SOURCES]** **Interface** MyIntf **[CDL][STUB_SERVER][SOURCES]** **Client** MyClient **[CDL]**[STUB_CLIENT][SOURCES] **Engine** MyEng **[CDL][DYNAMIC][SOURCES]** **Schema** MyShma **[CDL][LIBRARY][SOURCES][DOC]** **Toolkit** MyTk **[LIBRARY][SOURCES]** **Get** DevelopmentUnitName::Type:::File ~~~~~ \* Without mention of the version 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: **Name** The full name of the current delivery, including a version number. This is the name of the parcel. **Put path** Requires that the delivery be inserted in the user path (bin directory). **[CDL]** Copy the cdl files to the delivery. **[LIBRARY]** Generate the static library. Copy the shareable library to the delivery. Copy the list of objects of the library. **[INCLUDES]** Generate includes.origin. Copy the includes to the delivery. Copy the ddl to the delivery. **[DYNAMIC]** Select to copy the static or dynamic executable file. **[SOURCES]** Copy the source files. Build the Delivery ----------------- To build the delivery unit, use the command: ~~~~~ > umake ~~~~~ The result of building a delivery unit is a **parcel**, which can be installed in a warehouse and used by other workbenches. Sample Delivery of a Parcel --------------------------- 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: 1. Move to the root workbench under which the parcel is to be made. ~~~~~ > wokcd MyRootWb ~~~~~ 2. \*Create MyDelivery in MyRootwb. ~~~~~ > ucreate -d MyDelivery ~~~~~ 3. Move to the source directory of MyDelivery. ~~~~~ > wokcd MyDelivery ~~~~~ 4. Use an editor to list all the prerequisites and components of the delivery in the COMPONENTS files using the appropriate syntax. 5. Build MyDelivery. ~~~~~ > umake MyDelivery ~~~~~ The output of the umake process is a parcel Umake Steps for a Delivery Unit ------------------------------- The umake steps for development units of type delivery are explained below. * src                         Processes FILES to list source files. * base     Creates directories, defines the list of units, copies the parcels and the release notes. * get.list                   Lists files to get (using Get, Resource). * get.copy    Copy the files listed by get.list. * cdl.list                   Lists CDL files to copy. * cdl.copy    Copies the files listed by cdl.list. * source.list Lists units from which sources are to be copied. * source.build           Creates a file for sources (in the format: unit.type.Z). * inc.list                    Lists includes to copy. * inc.copy    Copies files listed by inc.list. * lib.shared   Works out the inputs for building or copying shareable libraries. * lib.shared.build Copies or builds (depending on the platform) the shareable libraries. * lib.server.list          Lists interface files to copy. * exec.list     Lists inputs for executable delivery. * exec.build Creates executable in the parcel. * files                       Works out the list of files delivered in the parcel. @subsubsection occt_wok_3_8_2 Installing a Parcel You open the root workbench of the workshop where you want to install the parcel using the following command: ~~~~~ > wokcd ~~~~~ To install the parcel, use the following syntax: ~~~~~ > pinstall ~~~~~ @subsection occt_wok_3_9 Working with Resource Building a Resource ------------------- There is a single umake step for development units of resource type. * src                         Processes FILES to list source files. @subsection occt_wok_3_10 Java wrapping @subsubsection occt_wok_3_10_1 Creating an interface To create an interface development unit and move to its structure, use commands: ~~~~~ > ucreate -i > wokcd ~~~~~ Writing an Interface -------------------- 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: ~~~~~ interface MyInterface uses   ListOfPackages; is   ListOfPackages;   ListOfClasses;   ListOfMethods; end; ~~~~~ Building an Interface --------------------- To make the services of the interface available for further wrapping, build the interface, using the command: ~~~~~ > umake [] -o src ~~~~~ Sample Construction of an Interface ---------------------------------- 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. 1. \*Create MyInterface in MyWb. ~~~~~ >ucreate -i MyInterface ~~~~~ 2. Move to the source directory of MyInterface. ~~~~~ >wokcd MyInterface ~~~~~ 3. Edit the source file MyInterface.cdl. You do this outside tcl, using an editor of your choice. 4. Build the interface. ~~~~~ > umake -o src ~~~~~ Interface Files --------------- Primary files for an interface .cdl - primary interface file Umake Steps for an Interface ---------------------------- The umake steps for development units of type interface are explained below. * src - processes MyInt.cdl to list the CDL files for the development unit. Processes the FILES file to list source files. **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. @subsubsection occt_wok_3_10_2 Creating a jni To create a development unit of type jni and move to its structure, use commands: ~~~~~ > ucreate -j > wokcd ~~~~~ Writing a Jni ------------- Use an editor to write a .cdl file that specifies the interface or interfaces required by the jni. This file has the following format: ~~~~~ client MyJni is {interface MyInterface;} {interface YourInterface;} end; ~~~~~ Building a Jni -------------- To wrap services exported by the interfaces to Java, build the jni, using the command: ~~~~~ > umake [MyJni] ~~~~~ Sample Construction of a Jni ---------------------------- 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. 1. \*Create MyJni in MyWb. ~~~~~ > ucreate -j MyJni ~~~~~ 2. Move to the source directory of MyJni. ~~~~~ > wokcd MyJni ~~~~~ 3. Edit the source file MyJni.cdl. You do this outside tcl, using an editor of your choice. 4. Derive Java files (.java and .class files) and C++ files (.h and .cxx) used for wrapping. ~~~~~ > umake -e xcpp ~~~~~ 5. Compile the sources. ~~~~~ > umake -o obj ~~~~~ 6. Link the object files. ~~~~~ > umake -o exec ~~~~~ Jni Files --------- Primary jni file is *Jni.cdl* Derived Java files for a Jni ---------------------------- *_.java* - Java source file of the class to be wrapped. *_.class* - Compiled java source file. Derived C++ files for a Jni --------------------------- *___java.h* - Include file for the C++ implementation of JNI. *___java.cxx* - C++ implementation of JNI. Umake Steps for a Jni --------------------- The umake steps for development units of type jni are explained below. * src        Processes MyJni.cdl to list the CDL files for the development unit. Processes the FILES file to list source files. * xcpp.fill     Compiles the internal data structure to prepare for subsequent extractions. * xcpp.client        Extracts the services declared in included interface unit(s) into Java and creates .java and *_java.cxx files. * xcpp.javac Compiles .java files into .class files. * xcpp.javah Creates .h header files. * obj.comp   Compiles generated C++ files. * obj.idep     Generates dependency information for the unit. * exec.libs    Computes full implementation dependency to prepare for linking. * exec.tks     Performs toolkit substitution. * exec.link    Generates the shared library for the development unit. @subsection occt_wok_3_11 More Advanced Use @subsubsection occt_wok_3_11_1 Default User Profile There is a default user profile. If you wish to change this profile the command wokprofile is available. You display the current profile using the command *> wokprofile* An example profile is given below. ~~~~~ Info : Profile in : WOK:k1dev:ref Info : Extractor : DFLT Info : Compile Mode : Optimized Info : Station Type : sil ~~~~~ @subsubsection occt_wok_3_11_2 Changing Parcel Configuration 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: ~~~~~ .edl. ~~~~~ Move to the admin directory of the factory: ~~~~~ > wokcd -PAdm ~~~~~ Then use the editor of your choice to edit the admin parameter file, MyWorkshop.edl. In this file, the parcel configuration is defined by an entry of the form: ~~~~~ \@set %_ParcelConfig = “Parcel1 Parcel2...Parceln”; ~~~~~ The resources are listed within quotation marks. They are separated by spaces. Edit this list as required. Save the file and close it. To validate and take into account your changes use the command: ~~~~~ > wokclose -a ~~~~~ This command closes and reopens all the entities. Without the -a option, *wokclose* only applies to the current entity. @section occt_wok_4_ Available Services @subsection occt_wok_4_1 Synopsis WOK provides sets of services, which can be grouped according to the entity they apply to: * General Services * Factories * Warehouses * Parcels * Workshops * Workbenches * Development Units * Source Management Services * Session Services @subsubsection occt_wok_4_1_1 Common Command Syntax Command Names ------------- 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. The following prefixes exist: * f: for factories * s: for workshops * w: for workbenches * u: for development units * W: for warehouses * p: for parcels * wok: for commands that apply to any type of entity These prefixes are followed by a command that determines the action to be executed. Examples of such commands are: * create: create an entity * rm: delete an entity * info: request information Consequently, the command ucreate creates a development unit. The command wrm removes a workbench. Command Options --------------- All command options are expressed using a dash (-) followed by one or more key letters and, if applicable, an argument. For example: ~~~~~ > umake -f -o MyUnit ~~~~~ The compact version of this syntax is also valid: ~~~~~ umake -fo argument MyUnit ~~~~~ This syntax conforms to the POSIX recommendations for UNIX commands. For all commands, there is a –h option, which displays help on usage. Presentation of Commands ------------------------ The general syntax of the commands is presented in this document as follows: ~~~~~ CommandName [option(s) [] []] ~~~~~ Consequently, there are four general cases for a command: ~~~~~ CommandName CommandName [] CommandName [] CommandName ~~~~~ **Note** a few commands described in this chapter do not completely respect this syntax; for example, *create* and *rm*. As a rule, where an ** is given as an argument it specifies which entity the command applies to. Where no ** 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. @subsection occt_wok_4_2 General Services General services are commands that apply to any entity manipulated by WOK. This includes commands for: * Navigation * Managing parameters * Managing profiles. wokcd                   **Navigates** between different WOK entities. wokclose   **Closes **and reopens entities. wokenv      **Gets information **about the current WOK environment. wokinfo     **Displays **information common to all entities. woklocate **Locates **files within the development units. wokparam **Queries **parameters. wokprofile **Modifies **the parameters of the session. @subsubsection occt_wok_4_2_1 wokcd ~~~~~ wokcd wokcd wokcd -P [] ~~~~~ 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. Options: Moves to the home directory of the entity specified by , i.e. moves to the location given by the parameter: %wokcd _Home. -P [] Moves to the directory of the entity specified by . i.e. moves to the location given by the parameter: %_. If no entity path is specified, this command moves to the directory of the current entity. Possible values for are: Home, Adm and Src. Use the following commands to change directories within a development unit: **wsrc                      **To access the source files. **winc                      **To access the include files. **wobj                      **To access objects. **wlib                       **To access shareable libraries. **wbin                      **To access executables. **wadm                    **To access the workbench administration files. Examples -------- *wokcd* - Lists the current position. *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. *wokcd -P Adm* - Moves to the administration directory of the current entity. @subsubsection occt_wok_4_2_2 wokclose ~~~~~ wokclose [-a] ~~~~~ Closes and reopens entities, i.e. reloads them into memory thus taking any changes into account. Options: **-a** Closes and reloads all entities. Examples -------- ~~~~~ wokclose ~~~~~ Closes and reopens the current entity. ~~~~~ wokclose -a ~~~~~ Closes and reopens all the entities. @subsubsection occt_wok_4_2_3 wokenv wokenv -f -t csh Creates the file . This file is a script, which configures a C shell to mirror the current WOK environment. See the *Test Environments* section for more details. Options: **-f** - Specifies the name of the file to produce. **-t csh** - Produces a file for configuring a C shell. **-s** - Sets up environment variables for application launching. Example ------- ~~~~~ > wokenv -f MyTestEnvScript -t csh ~~~~~ Generates the shell script MyTestEnvScript to configure a C shell so that it mirrors the current WOK environment. @subsubsection occt_wok_4_2_4 wokinfo ~~~~~ wokinfo -