dtcodegen(1) UNIX System V (1 August 1995) dtcodegen(1)
NAME
dtcodegen - generate code from a CDE application building
services project or module file
SYNOPSIS
dtcodegen [-changed] [-main] [-merge] [-nomerge]
[-module mymod] [-p|-project myproj] [-np|-noproject]
[-showall] [-noshowall] [-s|-silent] [-v|-verbose]
[file ...]
dtcodegen-help
DESCRIPTION
The dtcodegen utility reads Builder Interface Language (BIL)
files created by the CDE application building services
graphical user interface and produces C, Motif and CDE
source code for the user interface and application elements
defined. The BIL files supplied can be individual module
files (files with a .bil suffix) or a project file (files
with a .bip suffix) that contains references to zero or more
module files.
OPTIONS
The following options are available:
-changed
Generate only source code for those modules that
have changed since the last time dtcodegen was run.
-help
Write a help message to standard output explaining
all dtcodegen options and then terminate.
-main
Produce the project files associated with the
application's main() routine.
-merge
Merge generated stubs files with previous versions,
perpetuating changes made or custom edits done to
the previous stubs file. This is the default
behavior.
-nomerge
Do not merge existing and new _stubs.c files. This
option overrides the default merging behavior. If
both -merge and -nomerge are used, the one given
last on the command line takes precedence.
-module mymod
Generate code for the module mymod, (which is
expected to be defined in the file mymod .bil).
Page 1 (printed 9/3/04)
dtcodegen(1) UNIX System V (1 August 1995) dtcodegen(1)
Using multiple -module options includes multiple
modules in the generated code.
-p|-project myproj
Generate code for the project myproj, (which is
expected to be defined in the file myproj .bip).
-noproject
Ignore the project.bip project file and use default
project settings instead. This is useful in
producing an application from one or a few module
files (for example, for testing) as an alternative
to generating the entire project.
-showall
Cause the generated application to show (map) all
application windows (main windows and dialogs) at
startup, ignoring whether they are set to be
initially visible or not. If no project is
specified on the command line, either by using
-project or by specifying a project .bip file as an
operand, dtcodegen performs as if -showall had been
specified. (The -noshowall option suppresses this
behavior).
-noshowall
Cause the generated application to show at startup
(map) only those windows (main windows and dialogs)
whose initially visible attribute is true. If a
project is specified on the command line, either by
using -project or by specifying a project .bip file
as an operand, dtcodegen performs as if -noshowall
had been specified. (The -showall option
suppresses this behavior).
-s|-silent
Work silently, producing no output except error
messages while generating source code.
-v|-verbose
Be more verbose in providing progress and status
messages during the generation of source code.
OPERANDS
The following operand is supported:
file A pathname of a project or module file. It is not
necessary to specify the .bip or .bil extension for
any file because dtcodegen uses a sequence of
search algorithms in the current directory to
determine what files should be read in order to
satisfy the specified command line.
Page 2 (printed 9/3/04)
dtcodegen(1) UNIX System V (1 August 1995) dtcodegen(1)
If no file operands are given, dtcodegen searches
the current directory for a project file (a file
with a .bip suffix). If one is found, it is used
as if it had been specified on the command line.
If more than one is found, the first one
encountered is used.
If one or more file operands are specified,
dtcodegen checks to see if any of them is a project
file in the current working directory, and uses the
first one found. If none of the file operands are
project files, then the directory is searched for a
project file. This search is similar to the no-
operand case, but is modified to look for a project
file that contain modules corresponding to other
file operands.
Operands other than the project file are taken to
be module names.
See the EXAMPLES section for more on the interpretation of
filename operands and how the search features of dtcodegen
may be used.
RESOURCES
None.
STDIN
Not used.
INPUT FILES
All input files are text files in the BIL format. See
BIL(4).
ENVIRONMENT VARIABLES
The following environment variables affect the execution of
dtcodegen:
LANG Provide a default value for the
internationalization variables that are
unset or null. If LANG is unset or null,
the corresponding value from the
implementation-specific default locale
will be used. If any of the
internationalization variables contains an
invalid setting, the utility behaves as if
none of the variables had been defined.
LC_ALL If set to a non-empty string value,
override the values of all the other
internationalization variables.
Page 3 (printed 9/3/04)
dtcodegen(1) UNIX System V (1 August 1995) dtcodegen(1)
LC_MESSAGES Determine the locale that is used to
affect the format and contents of
diagnostic messages written to standard
error and informative messages written to
standard output.
NLSPATH Determine the location of message
catalogues for the processing of
LC_MESSAGES.
ASYNCHRONOUS EVENTS
The dtcodegen utility takes the standard action for all
signals.
STDOUT
When -help is specified, dtcodegen writes to standard output
a usage message in an unspecified format. Otherwise,
standard output is not used.
STDERR
When -verbose is specified, dtcodegen writes to standard
error informational progress messages and diagnostic
messages in an unspecified format. Otherwise, standard
error is used only for diagnostic messages.
OUTPUT FILES
The dtcodegen utility produces the following files:
modname_ui.c
The primary source code file for module modname,
containing C code to create the objects in the
module and establish connections for those objects.
modname_ui.h
Declarations and C externs for module modname.
modname_stubs.c
Callback functions for the element handlers
specific to module modname.
project.c
If dtcodegen is generating code for a project, this
file contains main() plus any callback functions
that are common across modules.
project.h
If dtcodegen is generating code for a project, this
file contains declarations for any callback
functions and C externs that are common across
interfaces.
.dtcodegen.log
Page 4 (printed 9/3/04)
dtcodegen(1) UNIX System V (1 August 1995) dtcodegen(1)
A record of per-module code generation and the date
and time of each module as it was processed. This
data is required to provide support for the
-changed option as part of determining which files
need to be regenerated and which ones do not.
Additional application code should be added to the
modname_stubs.c, project.c and project.c files, as
appropriate, because their contents are merged across runs
of dtcodegen.
EXTENDED DESCRIPTION
None.
EXIT STATUS
The following exit values are returned:
0 successful completion
>0 an error occurred
CONSEQUENCES OF ERRORS
Because code generation involves the sequential production
of a set of application files, errors that cause the
dtcodegen utility to exit prematurely also may result in
some module or project source files having been generated
while others were not. Attempts to build the application
from this mix of new and old generated code produce
undefined results.
APPLICATION USAGE
Typically the dtcodegen utility is used indirectly through
the CDE Application Builder's Code Generator dialog. This
allows application code to be generated while the user is
working with the Application Builder rather than through a
separate interface or shell command line. The Code
Generator dialog provides a graphical user interface for
dtcodegen that makes it easy to generate code, build the
resulting application and then execute it.
In some cases, however, it may be desirable to use the
dtcodegen utility directly. A common example of this usage
is to employ the code generator from within an application
Makefile to produce a portion of the application code from
pre-existing project or module files.
EXAMPLES
Run the code generator on the application defined by the
project file myproject.bip:
dtcodegen-p myproject
Page 5 (printed 9/3/04)
dtcodegen(1) UNIX System V (1 August 1995) dtcodegen(1)
Run the code generator for the project myproject.bip, but
only generate code for the module modulename.bil:
dtcodegen myproject.bip modulename
Search the current working directory for a project file that
references the module mymodule and then silently generate
code for just that module:
dtcodegen-silent mymodule
In the following example:
dtcodegen name1 name2
if the project file name1.bip exists, it is used and code is
generated for module name2.bil. Otherwise, both name1 and
name2 are taken as the name of modules, the current working
directory is searched for a project file that references
both modules, and code for those two modules is generated.
Run the code generator, which searches the current working
directory for a project file to be processed, and generates
all code associated with that project:
dtcodegen
Generate just the files associated with the main routine for
the project myproject, namely myproject.c and myproject.h:
dtcodegen-main -p myproject
Search the current working directory for a project file and,
if one is found, generate code for only those modules that
have changed since the code generator was last run:
dtcodegen-changed
Generate, for the project myproject.bip, code only for those
modules among the set module1, module2 and module3 that have
changed since the last time the code generator was run:
dtcodegen-changed -p myproject module1 module2 module3
SEE ALSO
dtbuilder(1), BIL(4).
Page 6 (printed 9/3/04)
