jepler/stepcode
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Start setting up standard README, COPYING, NEWS, etc. files

Browse source 
git-svn-id: https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/other/step@33987 2f96ce8b-6d43-0410-b8df-bffccc660ffb
This commit is contained in:
starseeker 2009-03-11 18:21:21 +00:00 committed by Mark Pictor
parent ee0830097b
commit 7865b16505
14 changed files with 966 additions and 2185 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
AUTHORS Normal file
View file

@ -0,0 +1,7 @@
/* National Institute of Standards and Technology (NIST)
* Manufacturing Engineering Laboratory (MEL)
* Factory Automation Systems Division (FASD)
*/

25
disclaim.txt → COPYING
View file

@ -1,8 +1,25 @@
/* National Institute of Standards and Technology (NIST)
* Manufacturing Engineering Laboratory (MEL)
* Factory Automation Systems Division (FASD)
* ********************************************************************
This software was produced by the National Institute of Standards and
Technology (NIST), an agency of the U.S. government, and by statute is
not subject to copyright in the United States. Recipients of this
software assume all responsibility associated with its operation,
modification, maintenance, and subsequent redistribution.
Acknowledgements:
The STEP Class Library (SCL) was developed by the Manufacturing
Systems Integration Division at NIST to support testing of the
Standard for the Exchange of Product Model Data (a.k.a STEP) and
validation of STEP's emerging implementation specifications. Funding
for the project has come from the Department of Commerce and the
Department of Defense agencies including the Office of the Defense
CALS (Continuous Acquisition and Life-Cycle Support) Executive and
the Defense Advanced Research Projects Agency (DARPA). Recent
enhancements were sponsored by the National Information Infrastructure
Protocols Consortium and NIST's Systems Integration for Manufacturing
Applications (SIMA) program.
/* ********************************************************************
* D I S C L A I M E R
* (February 6, 1992)
*

14
ChangeLog Normal file
View file

@ -0,0 +1,14 @@
Pre-BRL-CAD changes:
************************************************************************
Updates from http://www.statik.tu-cottbus.de/fileadmin/project_dth/scl/
Jan 2005 - Mar 2006
************************************************************************
STEP Class Library Release 3.2 February 1998
************************************************************************
STEP Class Library Release 3.1 October 1997
************************************************************************
STEP Class Library and Data Probe release 2.1 June 1995
************************************************************************

128
Makefile
View file

@ -1,128 +0,0 @@
PDES_ROOT = `pwd`
ARCH_DIR = arch
message:
@echo " "
@echo "You can run \"make default\" to install the NIST STEP Class Library and "
@echo "the related EXPRESS Toolkit, EXPRESS Pretty Printer, and fedex_plus software"
@echo "using defaults from your path."
@echo "If... "
@echo "- the installation fails or "
@echo "- you didn't get the compilers, etc you expected or "
@echo "- you want to do multiple installations (using different compilers or "
@echo " other SCL options)"
@echo "then you will need to read the instructions in INSTALL"
@echo " "
default:: time
-@if [ -d $(ARCH_DIR) ]; then \
echo " " ; \
echo "***ERROR*** The directory \"$(ARCH_DIR)\" already exists. " ; \
echo " Move it aside or delete it or read INSTALL."; \
echo " " ; \
else \
echo " " ; \
echo "configure will create arch dir: \"$(ARCH_DIR)\"" ; \
echo "running \"configure --with-arch=$(ARCH_DIR)\""; \
configure --with-arch=$(ARCH_DIR); \
echo " " ; \
date ; \
echo " " ; \
fi
time:
@echo " "
@date
# only use these make rules after the everything else has been installed
scl_examples:
# trigger when installing scl
@echo "**************************************************************"
@echo "*********** building scl example ***********"
# in this example the example schema is installed
(mkProbe -l -i -R $(PDES_ROOT) data/example/example.exp example)
@echo "**************************************************************"
@echo "when you are through with the example, remove the directories"
@echo " src/clSchemas/example and arch/Probes/example "
@echo "**************************************************************"
(cd src/test; make )
@echo ""
dp_example:
# depends on running make install
@echo "**************************************************************"
@echo "*********** building example Data Probe ***********"
# in this example the example schema and Data Probe are not installed
(mkProbe data/example/example.exp example)
@echo "**************************************************************"
@echo "when you are through with the example, remove the directory"
@echo " example "
@echo "**************************************************************"
@echo ""
clean:
@echo "**************************************************************"
@echo "*********** cleaning up ***********"
cd src/express; make clean; cd $(PDES_ROOT);
cd src/exppp; make clean; cd $(PDES_ROOT);
cd src/fedex_plus; make clean; cd $(PDES_ROOT);
cd $(ARCH_DIR)/ofiles; make clean; cd $(PDES_ROOT);
# remove the installed example
cd $(ARCH_DIR)/Probes;
if [ -d example ]; then rm -r example; cd $(PDES_ROOT);
cd src/clSchemas;
if [ -d example ]; then rm -r example; cd $(PDES_ROOT);
fresh: clean
@echo "building EXPRESS Toolkit libraries"
cd src/express; co checkout; checkout; make install; cd $(PDES_ROOT);
cd src/exppp; co checkout; checkout; make install; cd $(PDES_ROOT);
@echo "building fedex_plus"
cd src/fedex_plus; co checkout;
checkout; make depend; make install; cd $(PDES_ROOT);
@echo "building the STEP Class Libraries"
cd $(ARCH_DIR)/ofiles; make depend; make build; cd $(PDES_ROOT);
# To create a tar file use the following command.
# You need to do this from a seperate dir
# if you want to have a top level dir different from ~pdevel.
# For example create a release dir called SCL.
# In it place links to all the dirs you need.
# i.e.
# $(SCL)/src
# $(SCL)/src/express
# $(SCL)/src/exppp
# $(SCL)/src/fedex_plus
# $(SCL)/src/clstepcore
# $(SCL)/src/clutils
# $(SCL)/src/cleditor
# $(SCL)/src/clprobe-ui
#
# and the bin, arch, man dir and any other files.
# Then run the tar command. The options mean
# c create
# v verbose
# h hard code links as files
# f file to create
# FF skip .o files and RCS files
# [X] file name of other files to exclude
# create a tar file of the current dir
# by following all the links but don't copy any RCS dirs
#SCL = DProbe3.0pre
#tarfile:
# tar cvhfFF $(SCL).tar $(SCL)
# $(SCL)/src/RCS
# $(SCL)/src/express/RCS
# $(SCL)/src/exppp/RCS
# $(SCL)/src/fedex_plus/RCS
# $(SCL)/src/clstepcore/RCS
# $(SCL)/src/clutils/RCS
# $(SCL)/src/cleditor/RCS
# $(SCL)/src/clprobe-ui/RCS
#
#
#
# $(SCL)

924
NEWS Normal file
View file

@ -0,0 +1,924 @@
************************************************************************
Updates from http://www.statik.tu-cottbus.de/fileadmin/project_dth/scl/
Jan 2005 - Mar 2006
The original SCL source distribution could not be cleanly un-archived
on case-insensitive file systems like Windows' NTFS because of a name
conflict.
SCL is mainly written in C++, but it also contains C sources, lex and
yacc sources (compatible to flex and bison) and csh and sh scripts.
The C++ sources, written in the 1990s, are not fully compliant to
ANSI/ISO C++. Updates have been made to base parts of SCL to ANSI/ISO
C++ (only the SPF interface, not the complete database system
interfaces or the dataprobe GUI). Some problems were also addresses
with newer UNIX-like systems.
There were also some issues with the configure script and some
makefiles which are addressed, as well as a new macro that is at
least required for gcc.
Remaing problem: The p21 file scanner of SCL currently
does not allow for comments within the parameter list of
data records. Only comments outside of data records are
accepted.
DISCLAIMER: Use at your own risk. These patches are
incomplete, may be incorrect, and are not endorsed
by NIST.
************************************************************************
What's New in the STEP Class Library Release 3.2
February 1998
mkProbe now prints a usage message showing allowable command line
arguments when it is run without arguments.
Extended the EXPRESS Pretty Printer:
- added command line options -a and -A to the exppp executable to
specify that the output should be alphabetized. Without the -a option
the order of the TYPEs and entities in the original EXPRESS is
preserved when pretty printing an EXPRESS file.
- Fixed a bug in the exppp toolkit where it would crash when handling
PROCEDUREs in EXPRESS.
- Extended the NIST Pretty Printer Toolkit to provide string and
buffer representations for EXPRESS USE and REFERENCE statements, and
for providing access to the EXPRESS SUPERTYPE statements.
Extended the STEP Class Library Toolkit capabilities including:
- adding additional dictionary constructs for representing EXPRESS:
SUPERTYPE statements, WHERE rules within entities, USE FROM clauses,
REFERENCE FROM clauses, global rules, PROCEDUREs, and
FUNCTIONS. Information about these objects is available but validation
based on it is not performed.
- enhanced fedex_plus C++ code generator to generate the necessary
dictionary objects for the above EXPRESS constructs for a particular
schema. Also enhanced schema dictionary code generation to add
information necessary to generate an EXPRESS schema (i.e. which
entities, types, global rules, USE and REFERENCE statements, etc are
associated with which EXPRESS schema dictionary object).
- added capability to generate EXPRESS from the above dictionary
constructs (e.g. USE, REFERENCE, global rules, functions, procedures,
etc.) and the existing dictionary constructs for EXPRESS schemas,
types, entities, and attributes.
- Fixed a bug in the casting functions for the classes handling
instances of SELECT TYPEs in EXPRESS.
e.g.
SdaiMeasure_value::operator SCLP23(Real)()
{
// was missing stmts such as these...
if( CurrentUnderlyingType () == config_control_designt_area_measure )
return _real;
if( CurrentUnderlyingType () == config_control_designt_context_dependent_measure )
return _real;
}
- Fixed an aggregate element TypeDescriptor (TD) pointer problem in
the dictionary. The TD pointer in the aggregate dictionary entry is
supposed to point at the TD representing the element type for the
aggregate. It pointed at the underlying or base type's TD (e.g. the TD
for STRING) instead of for the type which was specified in the EXPRESS.
For example where it should have pointed at a TD for a TYPE label -
where label is defined as TYPE label = STRING; END_TYPE - it pointed
at the TD for STRING. The TD for the aggregate element now points at
the TD for label.
- Fixed the casting operator for the class representing EXPRESS
enumeration types. It was returning the last element of the enum type
as the the default when the enum was unset. This choice predated enums
having an unset enum value. It now returns <enum_name>_unset as the
default when the enum is unset.
- cleaned up a bit of leaked memory. The memory leaked was mostly
handles to static memory.
- sdaiString not reading a value '' properly.
- sdaiString copy constructor mixing up undefined and unset values.
- dictionary objects handling and writing WHERE rule and UNIQUE rule
comments in EXPRESS. Added a data member
SCLstring _comment; // Comment contained in the EXPRESS.
to classes Where_rule and Uniqueness_rule. Also they have functions:
SCLstring comment_() const { return _comment; }
void comment_(const char* c) { _comment = c; }
to manipulate them. When writing EXPRESS for entities and types the
keywords WHERE and UNIQUE are only written if there are actual
rules. If there are only comments the keywords are written as a
comment.
**********************************************************************
What's New in the STEP Class Library Release 3.1
October 1997
The following is a list of enhancements which are found in the version
3.1 release of the SCL and Data Probe. It assumes you are familiar
with EXPRESS (ISO 10303-11). Familiarity with version 2.1 or higher
is a big plus.
-------------------
Easier Installation
-------------------
We created a script called configure using gnu's autoconf software.
The configure script is used to install the SCL release. Configure
automates the editing of multiple SCL files based on site-specific
information needed for installation. It performs checks against the
software and operating system environment to create a header file used
by SCL to handle commonly known software porting problem areas.
Finally, it builds all the SCL executables, scripts, and libraries.
Configure requires one command line argument specifying a name which
is used to create a directory. Configure installs the architecture and
environment specific SCL executables, scripts, libraries, and object
code is under this directory.
Configure accepts optional command line arguments to install the SCL
for use with optional software packages (like Orbix and/or
ObjectStore) and for use with different compilers on different
operating systems and/or machine architectures. Configure may be
executed several times to create several SCL builds under separate
architecture/environment specific directories. Each of these
directories is based on the same source code directory to minimize
space requirements. This is possible because the SCL source code was
created with preprocessor switches which allows the same source code
to be built for different purposes. Separate builds are also necessary
to use SCL with different C++ compilers since C++ object code is not
compatible between C++ compilers.
-----------------------------------------------------
Alignment with the C++ Binding (ISO 10303-23) to the Standard Data
Access Interface (SDAI, ISO 10303-22)
-----------------------------------------------------
SCL has been better aligned with the C++ binding (ISO 10303-23,
a.k.a. STEP Part 23) to SDAI. This has involved several name changes
for classes implementing base EXPRESS types and application-schema
defined EXPRESS types. The name changes were possible since these
types and classes have been moved to be encapsulated by a namespace
implemented via a struct definition. The namespace has been defined in
a way that offers great flexibility in avoiding name conflict with
other software packages (like X Windows, CORBA implementations, etc)
and your application code. The namespace name is easily changed if
necessary. As a result of adding a namespace a noticeable difference
in SCL use has occurred.
Use of underlying SCL classes and types are now wrapped in macros that
are defined in the file sclprefixes.h. This file is installed under
the arch directory which allows it to be adjusted as necessary for
each SCL software installation. For example, if a compiler or software
package has a problem handling the namespace mechanism via a struct
definition alternate macros can be used from the sclprefixes.h file
bypassing the namespace altogether. If a name conflict occurs when the
namespace is turned off macros can be used that add a name prefix to
SCL types and classes. Use of the macros when using SCL types and
classes is what allows for the flexibility in dealing with problem
areas when using SCL with other software.
An example of a name change and macro use: sdaiString has now become
SCLP23(String) which could translate to SDAI::String or SDAI_String
(depending on whether you use the SDAI namespace or not) or any other
namespace or prefix as is necessary. To change the SDAI namespace name
or prefix name the macro definition for SCLP23() could be changed in
the sclprefixes.h file.
The early bound access functions that are generated by fedex_plus from
EXPRESS defined entities have been updated to the latest version of
Part 23's C++ binding to SDAI. A previous early bound function defined
as "const SdaiLabel Name()" would now be defined according to Part 23 as
"const SdaiLabel name_()". *notice* that application schema defined
types are not yet defined in a namespace. Compatibility with previous
versions of SCL early bound functions has been maintained via the -a
fedex_plus option.
-----------------------------------------------------
SDAI Session Schema objects implemented (model_contents, extents, etc)
-----------------------------------------------------
Several classes and types defined as part of SDAI Part 23's Session
Schema have been implemented (where before they mostly had stub
functions). These have been implemented for use with or without the
ObjectStore object oriented database. Model_contents_<schema_name> is
now being generated by fedex_plus allowing Entity_extents to be
maintained for entities as desired.
-----------------------------------------------------
Object Oriented Database Capability Using ObjectStore
-----------------------------------------------------
SCL has been enhanced to optionally use the object oriented database
ObjectStore from ODI. The INSTALL file describes how to build the SCL
libraries for use with ObjectStore. The SCL libraries built for use
with ObjectStore may then be used to create persistent or transient
SCL objects. The transient objects use the ObjectStore transient
database.
The SCL application, fedex_os, uses an application schema written in
EXPRESS to generate additional code needed for use with ObjectStore.
Fedex_os is used in conjunction with fedex_plus for generating the C++
necessary to implement your application schema.
Although building SCL libraries for use with ObjectStore is
documented, instructions for building your application with SCL
libraries and ObjectStore is as of yet undocumented. The undocumented
steps for building an SCL/ObjectStore application are the steps
required to build any ObjectStore application. A person familiar with
building ObjectStore applications should be able to create a Makefile
able to perform these necessary steps.
A good starting point for creating a Makefile suitable for building an
SCL/ObjectStore application would be the Makefile generated using the
mkProbe script. The configure script (executed with the ObjectStore
options) generates a make_rules file which contains the necessary
Makefile macros for using ObjectStore. The mkProbe generated Makefile
already includes this make_rules file. The Makefile is set up to build
a simple application which uses the appropriate SCL and ObjectStore
libraries. The Makefile rules for building this application could be
used as a starting point for creating Makefile rules to build your own
SCL/ObjectStore application. (The example application code is not set
up to use ObjectStore.) Additional steps would need to be added to run
the ObjectStore schema generator (ossg), link with the additional
application-specific ObjectStore object files, run os_postlink, etc.
-------------------------------------------------------
Use of Orbix with SCL for Developing CORBA Applications
-------------------------------------------------------
SCL has been enhanced to be able to use Orbix for developing SCL
applications for use within the Common Object Request Broker
Architecture (CORBA). CORBA is used to provide an architecture for use
of objects within a distributed environment. Distributed communication
occurs by client applications communicating with servers through
Object Request Brokers (ORBs). Clients may be written to use any
number of programming languages provided the CORBA software vendor
(Orbix in this case) supports the language. We have only tested
clients written using C++. We may soon test JAVA clients.
The SCL application, fedex_idl, is used to create an Interface
Definition Language (IDL) schema from your application's EXPRESS
schema. The generation of IDL schemas by fedex_idl is according to
STEP's Part 26 Interface Definition Language binding to the SDAI. The
Orbix IDL compiler is then used to generate the client and server code
necessary for communication through an Orbix ORB. The SCL application,
fedex_plus, would then be run with the -c option on your application's
EXPRESS schema to generate the server implementation objects required
to build an Orbix server (it uses the TIE approach). You would be
required to write the C++ main() function for the server code.
Although building SCL libraries for use with Orbix is documented,
instructions for building your application with SCL libraries and
Orbix is as of yet undocumented. The undocumented steps for building
an SCL/Orbix application are the steps required to build any Orbix
application. A person familiar with building Orbix applications should
be able to create a Makefile able to perform these necessary steps.
A good starting point for creating a Makefile suitable for building an
SCL/Orbix application would be the Makefile generated using the
mkProbe script. The configure script (executed with the Orbix options)
generates a make_rules file which contains the necessary Makefile
macros for using Orbix. The mkProbe generated Makefile already
includes this make_rules file. The Makefile is set up to build a
simple application which uses the appropriate SCL and Orbix
libraries. The Makefile rules for building this application could be
used as a starting point for creating Makefile rules to build your own
SCL/Orbix application. (The example application code is not set up to
use Orbix.) Additional steps would need to be added to build the
additional server code you would need to write, register the server
with Orbix, build and link with the IDL compiler generated code, etc.
-----------------------------------------------------
Use of Orbix and ObjectStore with SCL
-----------------------------------------------------
SCL has been enhanced to be able to be used with Orbix and ObjectStore
providing a persistent server for use within a distributed CORBA
environment. We have used SCL in this way for two NIST projects: the
National Industrial Information Infrastructure Protocols project and
the National Advanced Manufacturing Testbed Framework project.
Once again, although building the SCL libraries for use with Orbix and
ObjectStore is documented (via installation using the configure
script), instructions for building your application to use Orbix and
ObjectStore is as of yet undocumented. See the previous two sections.
-----------------------
MULTIPLE SCHEMA SUPPORT
-----------------------
A library and Data Probe can now be generated for an EXPRESS file
containing multiple schemas. This is done primarily by dividing the
source code generated by fedex_plus into separate files. Separate
files are generated for each schema contained in the EXPRESS file. In
addition, often schemas are dependent on one another. This will be
the case if the schemas use and reference entities and types from each
other. If, for example, entity X in schema A is a subtype of entity Y
in schema B, X will not be processed until B in schema Y is processed.
Other such cases of interdependence occur if an entity in schema A
contains as an attribute an enumeration or select type defined in
another schema. To address such cases, fedex_plus may process a
schema in multiple passes. At each pass, only the objects in the
schema which are not dependent on not-yet-processed objects in other
schemas are processed. At each successive pass through the schemas as
more and more objects are processed, more and more dependent entities
will become processable. Certain schemas may require three passes or
more in cases of chains of dependence (such as A being a supertype of
B which is a supertype of C, etc.).
For an EXPRESS file with multiple dependent schemas, it is advisable
to organize the file with bottom-up design. Schemas containing the
simpler, building block types and entities should appear first. By
doing so, when fedex_plus begins processing the more complex schemas,
there will be fewer cases in which the parser will encounter not-yet-
defined objects from other schemas. (The objects which are referenced
the most will have already been defined.) This will minimize the
number of times fedex_plus is required to divide output files.
One known case of interdependence which fedex_plus is not able to
support occurs if say select A has select B as an item, and select B
has select A as an item. (This is unsupported even if A and B are in
the same schema.) fedex_plus has no way in which it can generate
compilable source code for the selects because each is dependent on
the other. In addition, this would cause the parser to fall into an
endless loop, so we strongly discourage it. ;-)
------------------------------
USE / REFERENCE CLAUSE SUPPORT
------------------------------
The SCL also partially supports the EXPRESS concepts of USE and
REFERENCE. According to the rules of EXPRESS, schema A may reference
objects from schema B by way of a USE or REFERENCE clause (U/R). Any
object which is not U/R'ed from schema A to B, directly or indirectly,
is not visible to B. The SCL does not support the hiding of objects
between schemas. Basically, an object defined anywhere in the SCL is
visible everywhere else. What is supported is renamings of objects
between schemas. Say schema B uses entity X from schema A and renames
it to Y (i.e., "USE from A (X as Y);"). If a Part 21 file is read in
or written out using the SCL or the Data Probe, if the "current"
schema is defined to be B, the renamings defined by B's U/R statements
will be used. The "current" schema is set according to the first
schema listed in the FILE_SCHEMA section of the Part 21 file's header
section. (It is assumed that I/O is being done with the SCL's
STEPfile object.) If no current schema is defined, all possible
entity and type names are recognized in file reading, and the original
names only are used in writing.
As mentioned above, the SCL does not support the hiding of objects of
say, schema A, which are not U/R'ed by schema B. Thus, it's possible
to use the SCL or Data Probe to read or write a Part 21 file in which
A is the current schema and which contains instances of entities which
are not U/R'ed by A. This will not be flagged as an error.
The U/R clause is more poorly supported by the Data Probe. When the
Probe displays instances of entities, only their original names are
displayed. (This also applies when an entity has a select attribute
and the current choice of the select is being displayed by name. For
example, if a select is set to HEIGHT(35), the original name of
`HEIGHT' is displayed even if we're in schema B which renames HEIGHT
to LENGTH.) When a user is using a <<step entity editor window>> to
create an instance of an entity, all possible names for a type are
recognized. This includes the original object name plus all names
given to it by other U/R'ing schemas, regardless of the current
schema.
Another shortcoming with the U/R support is related to the fact that
the SCL does not allow objects of the same name in different schemas.
For this reason, U/R support is also limited to cases where the new
name is unique within the entire EXPRESS file.
Lastly, the U/R support is unable to deal with aggregate types of
two or more dimensions. Say we were attempting to instantiate a 2D
aggregate of selects. Type names will appear in the inner select
instantiations, and they should be set according to the current
schema. However, since the SCL currently does not fully support
higher-dimension aggregates (it uses the SCLundefined class and
considers the entire instantiation a string), it's impossible to
verify the values within the aggregate instance.
----------------------
COMPLEX ENTITY SUPPORT
----------------------
By complex entity, I mean ones which require external mapping (see Part 21,
section 11.2.5).
New Features
------------
(I really think the structures and functions I used to support this
are a recursive work of art. Too bad it's all invisible to the user.)
1. The primary enhancement now included is the checking of the
legality of complex entities. If a user attempts to initialize a
complex entity (class STEPcomplex), the SCL will determine, based on
the supertype and subtype information of the EXPRESS, if the entity
represents a legal combination of entities. If not, an error message
will be issued, and a complex entity will not be created. Formerly,
the SCL would only check if the entity names themselves were valid and
not worry about the combination.
2. Non-independent entities cannot be instantiated. These are
entities which cannot be created without external mapping. Say we
have,
ENTITY A SUPERTYPE OF (B AND C);
The SCL would not accept an instantiation statement such as,
#11=C(xx,yy,...);
C requires external mapping since it can only exist together with B,
in a statement such as,
#11=(A(...)B(...)C(...));
If a user attempts to create a C with internal mapping using the
STEPfile object (the class which handles all reading and writing of
Part 21 files within the SCL), an entity will not be created and an
error message will be issued. The SCL behaves similarly if a user
attempts to create an instance of an abstract supertype.
The above behavior is also reflected in the Data Probe. All entities
which are abstract supertypes are marked with an `*' (as in SCL vn.
2.1). Entities which cannot be instatiated without external mapping
are marked with a `%'. Neither can be created using the Data Probe.
(The Probe does not have the capability of creating complex entities,
see below, next section.)
(Note: A user can instantiate an entity such as C from the STEPentity
level, bypassing STEPfile. STEPentity will allow the initialization
but will place a warning in its errorDesc field.)
3. fedex_plus may be compiled with the flag COMPLEX_INFO. If this
flag is turned on, fedex_plus prints out (to `cout') a large amount of
detail on the complex entities it finds and their overall structure.
This is useful to see how fedex interpreted the complex information of
an EXPRESS file, and to get a simple graphical view of the supertype-
subtype hierarchy of the file.
fedex_plus's makefile contains the commented-out line,
#USER_DEFS = -DCOMPLEX_INFO
If this line is uncommented, a fedex_plus executable will be built
which prints such information.
Limitations
-----------
1. As in multi-schema support (above), complex entity (CE) support is
not completely reflected in the Data Probe. This may be seen in a
number of instances (you can skip this if you don't intend to use the
Probe):
(a) It's impossible to create an instance of a CE using the Data
Probe. (See point #2 under "Complex Entity Support").
(b) The Data Probe is able to correctly read a CE from a Part 21 file,
and place a copy of it in the Entity Instance List Window. It also
allows the user to edit the values of the entity's attributes by
selecting the entity (from the Ent Instance List Win) and creating a
STEP Entity Editor Window. The Data Probe, however, does not accu-
rately display the type information of the CE (in the Type Information
Window). What it does do is takes the name of the 1st entity in the
list (CE entity names are displayed alphabetically) and shows the type
info for that entity.
2. The SCL does not read partial complex instances. Generally, if a
single entity-member of a complex entity has an error, the entire rest
of the complex entity will be skipped.
3. If entity members of a complex entity have been renamed (through
the EXPRESS USE/REF clause - see previous section), they are read and
written properly. However, the SCL may not write the members of the
CE in alphabetical order (as required by Part 21, sect 11.2.5.3). The
individual entities are sorted according to their original names. If
the renaming of an individual entity places it out of order, the nodes
will be printed out of order.
4. "Diamond inheritance" is not handled automatically and must be
fixed by hand in the code generated by fedex_plus. (See
whatsnew.2-1.txt, section "Multiple Inheritance".)
5. Selects between aggregates: A select containing two aggregate
choices of the same type (e.g., ARRAY and ARRAY, as opposed to ARRAY
and SET) will cause fedex_plus to generate code which cannot be
compiled.
6. Problem with sparcworks compiler version 4.0(?) - operator int() =
op enum(). This happens in the following case... Both functions,
however, are required by Part 23. We fixed this by removing enough
functions for it to build. We were not sure if this error is the fault
of the sparcworks compiler or is a problem with the standard.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!DISCLAIMERS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Names of companies and products are provided in order to adequately
specify procedures and equipment used. In no case does such
identification imply recommendation or endorsement by the National
Institute of Standards and Technology, nor does it imply that the
products are necessarily the best available for the purpose.
NO WARRANTY
===========
NIST PROVIDES ABSOLUTELY NO WARRANTY. THE NIST STEP TOOLKIT
IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS
WITH YOU. SHOULD ANY PORTION OF THE NIST STEP TOOLKIT PROVE DEFECTIVE,
YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.
IN NO EVENT WILL NIST BE LIABLE FOR DAMAGES, INCLUDING ANY LOST
PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE, OR LOSSES
SUSTAINED BY THIRD PARTIES, OR A FAILURE OF THE PROGRAM TO OPERATE
WITH PROGRAMS NOT DISTRIBUTED BY NIST) THE PROGRAMS, EVEN IF YOU HAVE
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY
ANY OTHER PARTY.
**********************************************************************
What's new in the STEP Class Library and Data Probe release 2.1
June 1995
This release of the STEP Class Library (SCL), fedex_plus code
generator, and Data Probe also contains the latest releases of the
fedex syntax and semantic checker, the NIST Express Toolkit (also new
on SOLIS as of June 12, 1995), and the Express Pretty Printer Toolkit.
The NIST Express Toolkit and fedex have been updated to handle the IS
version of Express and various problems have been fixed as a result of
pre-validation conformance testing. Following is an overview of
what's new in the STEP Class Library (and hence fedex_plus) and the
Data Probe.
--------------------
*Compilers supported:
--------------------
The SCL and Data Probe now compiles with gnu C++ v2.5.8, v2.6, and
Sun C++ v3.0.1. The SCL also compiles with ppCC, the pre-processor of
the Open OODB from TI.
-------------------
*Complex Instances:
-------------------
The SCL now supports instantiation of complex instances via a class
called STEPcomplex. The SCL supports reading and writing of complex
instances from/to Part 21 and Working files using the external mapping
specified in Part 21.
Complex instances are created by calling the constructor for
STEPcomplex with a list of entity name strings. The combination of
entity names that are passed in to become part of the complex instance
are not validated to determine if they are a legal set of entities
with regard to the inheritance structure specified in Express.
Attributes within each of the represented entities are validated as
usual.
An entity hierarchy with triangle and circle both inheriting from
shape with andor inheritance would allow creation of a
circle-shape-triangle entity. Here is an example of how such an
object could be created.
SCLstring *entNmArr[64]; // array of entity type names
int fileid = 1;
Registry *registry = new Registry(SchemaInit);
entNmArr[0] = new SCLstring("shape");
entNmArr[1] = new SCLstring("triangle");
entNmArr[2] = new SCLstring("circle");
entNmArr[3] = 0;
STEPentity * obj = new STEPcomplex(&_reg, (const SCLstring **)entNmArr,
fileid);
In the same manner the toolkit would allow a user to create a
circle-shape-triangle-color entity even if it was not valid given the
Express.
The complex instances implementation has a late bound flavor. The
instances do not have code generated implementing attribute access
functions with names matching the name of the attribute. This method
of access, normally associated with an early binding, is available for
non-complex instances and is partially available for instances
involving multiple inheritance. The complex entity instance's
attributes are accessible through the STEPattribute class in a manner
similar to the non-complex instances.
The Data Probe reads and writes complex instances from/to Part 21 and
Working files but supports very limited editing of complex instances.
----------------------
*Multiple Inheritance:
----------------------
The SCL offers two choices to users in handling multiple inheritance.
These include the method offered by SCL in previous releases and the
current method. The current method handles attributes inherited from
all parents. It does not correctly handle multiple inheritance where
an entity has more than one path through parents to a common ancestor.
One could imagine this case as a diamond shaped inheritance structure.
When this case of multiple inheritance is encountered attributes are
duplicated. This case of multiple inheritance may possibly be
avoided by modifying the EXPRESS schema by breaking some links in the
inheritance hierarchy. This will not have an adverse affect on the
implemementation. The user may choose to use the current or previous
method of handling multiple inheritance. The current method is the
default behavior. The previous method is obtained by supplying the
-s (or -S) option with the fedex_plus code generator or the mkProbe
script.
When the fedex_plus code generator is generating the C++ class library
representation of a schema, it outputs information calling attention
to the cases of multiple inheritance.
The previous method of handling multiple inheritance:
This method of handling multiple inheritance is useful where
attributes are inherited from only one parent. It does not allow an
entity instance to be casted in C++ to a class representing
non-implemented parents. These multiply inherited instances are
created in the same manner as non-multiply inherited, non-complex
instances.
For each entity that has multiple parents the first parent that
contains or inherits attributes is used in the inheritance hierarchy
for the C++ class representing the entity. In each case of multiple
inheritance the parents are searched for attributes in the same order
as they were specified for the entity in Express. Once attributes
have been found associated with one parent, attributes from other
parents are ignored. All attributes handled have access functions.
The current method of handling multiple inheritance:
Multiply inherited instances are created in the same manner as
non-multiply inherited, non-complex instances. These include calling
any of the following functions:
1. the constructor of the entity class.
2. Registry::ObjCreate() with the name of the entity as a string argument.
3. EntityDescriptor::NewSTEPentity() from the dictionary entry
associated with the entity to be created.
a c e
| | | This hierarchy modeled in Express turns into
b d f the data structures pictured below.
\ | /
\ | / h
\|/ /
g -
Each STEPentity also has a pointer back to g's STEPentity.
STEPentity STEPentity STEPentity
-------------------- -------------------- --------------------
| - attribute list | | - attribute list | | - attribute list |
| for a, b, c, d,| | for c and d | | for e and f |
| e, f, h, and g | | (in that order)| | (in that order)|
| (in that order)| | | | |
| - pointer to | | - pointer to | | - pointer to |
| STEPentity ----+--->| STEPentity ----+--->| STEPentity ----+----
| - pointer to | | - pointer to | | - pointer to | |
| dictionary | | dictionary | | dictionary | |
| entry for g | | entry for d | | entry for f | |
-------------------- -------------------- -------------------- |
| | | |
a c e |
---------------------- ---------------------- ---------------------- |
| - attributes for a | | - attributes for c | | - attributes for e | |
| - access functions | | - access functions | | - access functions | |
| for a | | for c | | for e | |
---------------------- ---------------------- ---------------------- |
| | | |
b d f |
---------------------- ---------------------- ---------------------- |
| - attributes for b | | - attributes for d | | - attributes for f | |
| - access functions | | - access functions | | - access functions | |
| for b | | for d | | for f | |
---------------------- ---------------------- ---------------------- |
| |
g |
---------------------- |
| - attributes for g | |
| - access functions | |
| for g | |
---------------------- |
|
STEPentity <-----------
--------------------
| - attribute list |
| for h |
| - pointer to |
| STEPentity |
| - pointer to |
| dictionary |
| entry for h |
--------------------
|
h
|
----------------------
| - attributes for h |
| - access functions |
| for h |
----------------------
Multiply inherited entities have two early bound access functions
associated with all of the attributes - one for get attribute value
and one for set attribute value. These access functions have the same
name as the attribute. The requirement for use of these access
functions is that they must be called from the appropriate part of
the data structure representing the multiply inherited instance. C's
attribute access functions could be called from a pointer to the C or
D part of the data structures shown above. Functions are supplied for
accessing the appropriate part of the data structure.
a
/ \ An Express schema containing this type of inheritance hierarchy
| | under the current multiple inheritance implementation will cause
b c attributes for 'a' to be duplicated.
| |
\ /
d
The Data Probe fully supports the SCL implementation of multiply
inherited entity instances. Inside a STEP Entity Editor window,
attribute dictionary information is displayed as usual for all
attributes in multiply inherited entity instances. It currently,
however, only displays the first parent encountered each step up the
parent hierarchy when displaying Express dictionary information for
the entity as a result of pressing the Type Information button.
------------------
*Part 21 Comments:
------------------
The SCL now handles comments associated with Part 21 and SCL Working
files. It saves comments preceding an entity instance with the entity
instance that follows. It can handle saving all the comments in the
example below. All the comments would be saved as part of entity
instance #1.
/*comment 1*/ /*cmt 1.5 */
#1/*cmt 2*/=/*cmt 3*/ORGANIZATION/*cmt 4*/( 'hi','foo','bar')/*cmt 5*/;/*cmt6*/
#2=ORGANIZATION('ab','cd','ef');
When writing instance #1 above to a Part 21 or Working file, all
comments that have been saved with the instance will be written out
separately preceding the instance as follows.
/*comment 1*/
/*cmt 1.5 */
/*cmt 2*/
/*cmt 3*/
/*cmt 4*/
/*cmt 5*/
#1=ORGANIZATION('hi','foo','bar');
/*cmt6*/
#2=ORGANIZATION('ab','cd','ef');
Part 21 comments are also read and written for header entity instances.
Part 21 comments are supported in the Data Probe. Comments associated
with an entity appear in the comment field on the STEP Entity Editor
window. The comment (formerly "label") field accepts comments that
will be saved to a Part 21 or Working file and comments that are not.
Comments written as valid Part 21 comments (i.e. enclosed in /* */)
will be saved in files. Non-Part 21 text will only last until the end
of the Data Probe session or until the entity is deleted, whichever
comes first.
---------
*Selects:
---------
The way SCL handles selects for editing and writing part 21 files has
been updated. Here are the new rules.
- If there is only one choice in the select (i.e. a select of one
type), the value for that choice can be entered without qualification.
- If the select is between entities only (and not via nested selects),
the element types are assumed to be unique and values can be entered
as a reference to an entity instance.
- In all other cases the value must be qualified by enclosing the
value in the type of the select item.
- These rules apply to editing in the Data Probe, as well as reading
from and writing to a file.
When editing a select attribute in the Data Probe STEP Entity Editor
window, mouse clicking the edit button offers support for qualifying
the select attribute value. When you click the edit button for a
select attribute, and choose a type from the list, it is applied to
the attribute value field in the entity editor.
If there wasn't a value in the attribute previously, then the field will
contain just the type specifier, e.g., Str1() if Str1 is the type selected.
If a value exists in the field, it is modified to accomodate the new
specifier. This means the following:
o If the value in the field starts with a single-quote ('), it is
assumed to be a string literal, and is completely wrapped in the new
specifier (e.g., 'foobar' --> Str1('foobar') ).
o If the value starts with an open-paren ('('), it is assumed to be an
aggregate literal, and is wrapped in the new specifier as above.
o If the value already has a specified type (e.g., Str1('foo')), things
get interesting. (By the way, containing a specified type is
determined by the existence of an open paren (after the first
character) encountered before end-of-string.) Ordinarily, the
type specifier is replaced by the new type, e.g.,
Str1(.enumval.) --> Enum1(.enumval.).
However, if the new type is a SELECT, then the whole value in the
field is wrapped in the new type specifier, e.g., Str1('foo') -->
Sel1(Str1('foo')) if the new type is Sel1. This is because it is
assumed that the user is qualifying the subtype of the SELECT before
'editing'. A possible future enhancement may check to see if
the field contains a valid select subtype, and if not, do a
replace as in the above Str1->Enum1 example.
If the field entry matches none of these cases, it is just wrapped in the
type specifier... actually, the only real reason for having the string
and aggregate special cases is that they contain (or can contain)
parentheses that would throw off checking for type specifiers...
Validation of all of this still occurs in the editing window as usual,
so if the user chooses something invalid, it is still flagged in the
STEP Entity Editor window.
---------
*Strings:
---------
Strings can now differentiate between a string that does not exist and
a string that has no elements. This may be done with the following
functions in the SCLstring class in scl_string.h:
// returns 1 if _strBuf is a null ptr or if it is an empty string (i.e. "")
int is_null() const;
// returns 1 if _strBuf is a null ptr, and 0 otherwise
int is_undefined() const;
// deletes _strBuf
void set_undefined() ;
// zeroes out space in _strBuf
int set_null() ;
The Data Probe now differentiates between a STRING attribute value
that does not exist and one that exists but contains no characters.
When editing an attribute of type string in a STEP Entity Editor
window, an attribute value containing only a dollar sign indicates that
the string attribute value does not exist. An attribute value
containing only a backslash followed by a dollar sign indicates a
string value of length one containing a dollar sign. The absence of a
value indicates that the string exists but contains no characters.
-------------
*Enumerations:
-------------
The access functions for enumerations now accept the associated C/C++
enumeration value rather than the enumeration class. Implicit calling
of casting functions makes it possible for instances of the
enumeration class still to be passed into the attribute's get
functions and to be assigned the return value of the attribute's put
functions.
--------
*Boolean:
--------
Attributes of type Boolean and aggregate of Boolean were previously
implemented using the Logical and Logicals classes (respectively).
The fedex_plus code generator now generates classes Boolean and
Booleans to implement attributes of type Boolean and aggregate of
Boolean respectively.
--------------------------------
*Public Data Member Name Changes:
--------------------------------
In class STEPentity:
Descriptor is now eDesc
In class STEPattribute:
Descriptor is now aDesc
The name change in STEPentity was to avoid symbol name conflicts of
STEPentity::Descriptor with access functions generated for Express
entity attributes named descriptor. The new name will not be
conflicting with any generated names since the letter case will never
match.

0
README.scl → README
View file

170
README.projdth
View file

@ -1,170 +0,0 @@
*************************************************
NOTE: this tarball is the scl3-2_cygwin.tar.bz2
tarball described below, with the change of binary
names for cygwin in the makefiles removed and this
file inserted.
The text below is the text form of the contents of:
http://www.statik.tu-cottbus.de/fileadmin/project_dth/scl/
as retreived Mar. 7, 2009
*************************************************
NIST STEP Class Library (SCL)
* What is SCL?
* Platform issues
* Installation
* Testing and using SCL
What is SCL?
SCL is basically a toolbox to build interfaces between
application programs and STEP data repositories. The
latter can be STEP physical files (SPF as defined by
ISO 10303-21) or object-oriented database systems, of
which two products are supported by SCL.
SCL was written by NIST for the U.S. government and is
therefore not subject to copyright. You may study it,
modify it, redistribute it, create free or non-free
software with it. For more information about SCL and in
order to get its original distribution, please refer to
the official SCL site at NIST:
http://www.mel.nist.gov/msidstaff/sauder/SCL.htm.
WSTEP, a free SCL port to Windows is available at
http://www.bauv.unibw-muenchen.de/~bauv1/download/WStep/
(ported by Stefan Schwarz).
Platform issues
The original SCL source distribution cannot be cleanly
un-archived on case-insensitive file systems like Windows'
NTFS because of a name conflict. Here is a source archive
with the conflicting file renamed:
scl3-2.tar.bz2.
Tar.bz2 archives can be unpacked with bzip2 and tar or
with the Windows program 7-Zip.
SCL is mainly written in C++, but it also contains C
sources, lex and yacc sources (compatible to flex and
bison) and csh and sh scripts. The C++ sources, written
in the 1990s, are not fully compliant to ANSI/ISO C++.
Here is a patch that updates base parts of SCL to
ANSI/ISO C++ (only the SPF interface, not the complete
database system interfaces or the dataprobe GUI).
The patch also addresses some problems with newer
UNIX-like systems:
scl3-2_isocpp.diff
There are furthermore some issues with the configure
script and some makefiles which are addressed by the
following patch. This patch also adds a macro that is at
least required for gcc:
scl3-2_build.diff
These patches were tested with gcc 3.3 under Linux, Mac
OS X, as well as Windows with Cygwin. Cygwin is a UNIX-like
environment for Windows with complete GNU toolchain. Some
further modifications are necessary to build SCL under
Cygwin:
scl3-2_build_cygwin.diff
A source archive with the three patches already applied
is provided here for your convenience:
scl3-2_cygwin.tar.bz2.
Remaing problem: The p21 file scanner of SCL currently
does not allow for comments within the parameter list of
data records. Only comments outside of data records are
accepted.
DISCLAIMER: Use at your own risk.
The patches are incomplete, may be incorrect, and are
not endorsed by NIST.
Installation
Install Linux, or Cygwin on Windows, or Fink on Mac OS X.
In either case you need the packages gcc-core, gcc-g++,
binutils, make, bison, yacc, sed, tcsh, tar, bzip2.
Under Linux or Mac OS X, unpack scl3-2.tar.bz2. Apply the
first two patches:
tar xfj ~/scl3-2.tar.bz2
cd scl3-2
patch -p1 < ~/scl3-2_isocpp.diff
patch -p1 < ~/scl3-2_build.diff
Under Windows + Cygwin, unpack scl3-2_cygwin.tar.bz2, do
not apply patches:
tar xfj ~/scl3-2_cygwin.tar.bz2
cd scl3-2
Build fedex, fedex_plus, exppp, mkProbe and a simple demo
called p21read with the command
./configure --with-arch=local
This takes less than 2 minutes on a 1.6 GHz PC. The results
are installed under "scl3-2/local/". Add the following
lines to ~/.bashrc:
MANPATH="${MANPATH}:~/scl3-2/man"
PATH="${PATH}:~/scl3-2/local/bin"
(Note: Instead of "local", you should use a more descriptive
name like "arch-cygwin" in the configure command and PATH
variable if you build for multiple architectures on the same
filesystem.)
Testing and using SCL
In order to build the Class Library and p21read for another
EXPRESS schema like IFC 2x2, use the following command. (
Note: You need a syntactically corrected version of the
schema: ifc2x2a1.exp.)
mkProbe -i -p ~/ifc2x2a1.exp ifc2x2
mkProbe builds and installs the library and p21read under
"scl3-2/local/Probes/ifc2x2/". This takes about 2 minutes on
a 1.6 GHz PC with Linux but 12 minutes on a 2.8 GHz PC with
Windows + Cygwin. The resulting executable is 5...20 MB big,
depending on the platform and whether you strip debug symbols
off of it. If you want to build only the library, not p21read,
omit -p from the mkProbe call.
Test p21read with some IFC data:
~/scl3-2/local/Probes/ifc2x2/p21read_ifc2x2 in.ifc out.ifc
assumed you provide an existing file "in.ifc". P21read simply
reads the file in.ifc, checks it, and writes its content back
into out.ifc.
Besides p21read, SCL comes with some other tiny demonstrators
which are built by the above configure command and installed
beneath "local/testbuild/": The demo tstatic creates instances
of entities in a compiled example EXPRESS schema, populates
their attributes, and prints them like they would appear in a
STEP file. The demo treg looks for all entities (classes)
contained in a compiled EXPRESS schema, creates an instance of
each entity with random attribute data, and creates a STEP file
of them. The demo tio reads objects from a STEP file, then reads
this file again and appends the objects to the existing model,
and writes the doubled model out to a STEP file.
While the demo tstatic works only with the provided example
schema, the demos p21read, treg, and tio work with any EXPRESS
schema you build a STEP Class Library for. Tstatic uses early
bound access functions, while the other demos use only late
bound access functions.
Stefan Richter, LS Statik & Dynamik
created 09 Jan 2005, updated 01 Mar 2006

10
checkout.config
View file

@ -1,10 +0,0 @@
co configure.in
co configure
co INSTALL
co configure.files_notes.txt
cd config/
co checkout
checkout
cd examples/
co checkout
checkout

3
config.log
View file

@ -1,3 +0,0 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

315
config.status
View file

@ -1,315 +0,0 @@
#! /bin/sh
# Generated automatically by configure.
# Run this file to recreate the current configuration.
# This directory was configured as follows,
# on host allegro:
#
# configure --with-arch=arch-gnu-solaris
#
# Compiler output produced by configure, useful for debugging
# configure, is in ./config.log if it exists.
ac_cs_usage="Usage: ./config.status [--recheck] [--version] [--help]"
for ac_option
do
case "$ac_option" in
-recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)
echo "running ${CONFIG_SHELL-/bin/sh} configure --with-arch=arch-gnu-solaris --no-create --no-recursion"
exec ${CONFIG_SHELL-/bin/sh} configure --with-arch=arch-gnu-solaris --no-create --no-recursion ;;
-version | --version | --versio | --versi | --vers | --ver | --ve | --v)
echo "./config.status generated by autoconf version 2.7"
exit 0 ;;
-help | --help | --hel | --he | --h)
echo "$ac_cs_usage"; exit 0 ;;
*) echo "$ac_cs_usage"; exit 1 ;;
esac
done
ac_given_srcdir=.
trap 'rm -fr config/sclbuild.current config/mkProbe.current config/setup-arch.current arch_template/make_rules arch_template/testbuild/schema-loc arch_template/ofiles/sdaiOrbix/corbaIncludes.h arch_template/Probes/template-schema/Makefile.personal src/express/mkrules config/scl_cf.h conftest*; exit 1' 1 2 15
# Protect against being on the right side of a sed subst in config.status.
sed 's/%@/@@/; s/@%/@@/; s/%g$/@g/; /@g$/s/[\\&%]/\\&/g;
s/@@/%@/; s/@@/@%/; s/@g$/%g/' > conftest.subs <<\CEOF
/^[ ]*VPATH[ ]*=[^:]*$/d
s%@CFLAGS@%-g -O%g
s%@CPPFLAGS@%%g
s%@CXXFLAGS@%-g -O%g
s%@DEFS@%-DHAVE_CONFIG_H%g
s%@LDFLAGS@%%g
s%@LIBS@%%g
s%@exec_prefix@%${prefix}%g
s%@prefix@%/usr/local%g
s%@program_transform_name@%s,x,x,%g
s%@bindir@%${exec_prefix}/bin%g
s%@sbindir@%${exec_prefix}/sbin%g
s%@libexecdir@%${exec_prefix}/libexec%g
s%@datadir@%${prefix}/share%g
s%@sysconfdir@%${prefix}/etc%g
s%@sharedstatedir@%${prefix}/com%g
s%@localstatedir@%${prefix}/var%g
s%@libdir@%${exec_prefix}/lib%g
s%@includedir@%${prefix}/include%g
s%@oldincludedir@%/usr/include%g
s%@infodir@%${prefix}/info%g
s%@mandir@%${prefix}/man%g
s%@PDES_ROOT@%/proj/pdevel/scl3-1%g
s%@EXAMPLE_NAME@%example%g
s%@MAKE_EXAMPLE_NAME@%make -k%g
s%@ARCH_ROOT@%arch-gnu-solaris%g
s%@SUN_ARCH@%SUN5%g
s%@SET_MAKE@%%g
s%@CC@%/depot/gnu/arch/bin/gcc%g
s%@CC_PATH@%/depot/gnu/arch/bin/gcc%g
s%@CXX@%/depot/gnu/arch/bin/c++%g
s%@CPP@%/depot/gnu/arch/bin/gcc -E%g
s%@CXX_PATH@%/depot/gnu/arch/bin/c++%g
s%@RANLIB@%ranlib%g
s%@LEX@%/depot/pub/arch.sunos5.6/bin/flex%g
s%@LEXLIB@%-lfl%g
s%@LEX_PATH@%/depot/pub/arch.sunos5.6/bin/flex%g
s%@FLEX@%/depot/pub/arch.sunos5.6/bin/flex%g
s%@SCANNER@%FLEX%g
s%@LC_ONEA@% $(FLEX) $(FLEXFLAGS) $< > $*.flex%g
s%@LC_ONEB@%.c%g
s%@LC_TWOA@% $(UTIL)/uniquify_flex $*%g
s%@LC_TWOB@% %g
s%@LO_ONEA@% $(FLEX) $(FLEXFLAGS) $< > $*.flex%g
s%@LO_ONEB@%.c%g
s%@LO_TWOA@% $(UTIL)/uniquify_flex $*%g
s%@LO_TWOB@% %g
s%@LO_THREEA@% $(CC) $(CCFLAGS) -c $*%g
s%@LO_THREEB@%.c%g
s%@LOP_ONEA@% $(FLEX) $(FLEXFLAGS) $< > $%g
s%@LOP_ONEB@%*.c%g
s%@LOP_TWOA@% $(UTIL)/uniquify_flex $%g
s%@LOP_TWOB@%*%g
s%@LOP_THREEA@% $(CC) $(CCFLAGS) $(PROFILE) -c $%g
s%@LOP_THREEB@%*.c -o $%g
s%@LOP_THREEC@%@%g
s%@YACC@%/depot/gnu/arch/bin/bison -y%g
s%@YACC_PATH@%/depot/gnu/arch/bin/bison -y%g
s%@BISON@%/depot/gnu/arch/bin/bison -y%g
s%@YC_ONEA@% $(YACC) $(YACCFLAGS) -o $%g
s%@YC_ONEB@%*.tab.c $<%g
s%@YC_TWO@%# sed barf's on slashes, so expand them out here%g
s%@YC_THREEA@% cp $(UTIL)/bison.errors bison.sub%g
s%@YC_THREEB@% %g
s%@YC_FOURA@% cat $%g
s%@YC_FOURB@%*.tab.c | sed -e '/yyerror("parse error");/r bison.sub' -e '/yyerror("parse error");/d' > tmp.c%g
s%@YC_FIVEA@% rm bison.sub%g
s%@YC_FIVEB@% %g
s%@YC_SIXA@% mv tmp.c $%g
s%@YC_SIXB@%*.tab.c%g
s%@YC_SEVENA@% $(UTIL)/uniquify_yacc $%g
s%@YC_SEVENB@%*%g
s%@YC_EIGHTA@% $(BISONTOKENS) $%g
s%@YC_EIGHTB@%*%g
s%@YO_ONEA@% $(BISON) $(YACCFLAGS) -o $%g
s%@YO_ONEB@%*.tab.c $<%g
s%@YO_TWOA@% $(UTIL)/uniquify_yacc $%g
s%@YO_TWOB@%*%g
s%@YO_THREEA@% $(BISONTOKENS) $%g
s%@YO_THREEB@%*%g
s%@YO_FOURA@% $(CC) $(CCFLAGS) -c $%g
s%@YO_FOURB@%*.c%g
s%@YO_FIVEA@%#%g
s%@YO_FIVEB@%#%g
s%@YO_SIXA@%#%g
s%@YO_SIXB@%#%g
s%@YOP_ONEA@% $(BISON) $(YACCFLAGS) -o $%g
s%@YOP_ONEB@%*.c $<%g
s%@YOP_TWOA@% $(UTIL)/uniquify_yacc $%g
s%@YOP_TWOB@%*%g
s%@YOP_THREEA@% $(BISONTOKENS) $%g
s%@YOP_THREEB@%*%g
s%@YOP_FOURA@% $(CC) $(CCFLAGS) $(PROFILE) -c $%g
s%@YOP_FOURB@%*.c -o $%g
s%@YOP_FOURC@%@%g
s%@SCL_DEFS@% %g
s%@IV_ROOT_DIR@% %g
s%@MAKE_IVFASD@% %g
s%@MAKE_PROBEUI@% %g
s%@EXECUTABLE_MKPROBE@% %g
s%@IV_INCLUDE_DIR@%$(IVROOT)/installed/include%g
s%@INTERVIEWS_LIB_DIR@%$(IVROOT)/installed/lib/SUN5%g
s%@MKPROBE_OPTIONS@%-i -p%g
s%@OS_FLAGS@% %g
s%@OS_ROOTDIR@% %g
s%@OS_INC_DIR@% %g
s%@LIBOSC_LD@% %g
s%@LIBOSTHR_LD@% %g
s%@OS_LIB_DIR@% %g
s%@OS_LIBS@% %g
s%@CP_SCLPREFIXES@%cp sclprefixes.h.noOrbixOstore sclprefixes.h%g
s%@MAKE_SDAIORBIX@% %g
s%@ORBIX_INCS@% %g
s%@ORBIX_FLAGS@% %g
s%@ORBIX_MK_FILE@% %g
CEOF
CONFIG_FILES=${CONFIG_FILES-"config/sclbuild.current config/mkProbe.current config/setup-arch.current arch_template/make_rules arch_template/testbuild/schema-loc arch_template/ofiles/sdaiOrbix/corbaIncludes.h arch_template/Probes/template-schema/Makefile.personal src/express/mkrules "}
for ac_file in .. $CONFIG_FILES; do if test "x$ac_file" != x..; then
# Support "outfile[:infile]", defaulting infile="outfile.in".
case "$ac_file" in
*:*) ac_file_in=`echo "$ac_file"|sed 's%.*:%%'`
ac_file=`echo "$ac_file"|sed 's%:.*%%'` ;;
*) ac_file_in="${ac_file}.in" ;;
esac
# Adjust relative srcdir, etc. for subdirectories.
# Remove last slash and all that follows it. Not all systems have dirname.
ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'`
if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then
# The file is in a subdirectory.
test ! -d "$ac_dir" && mkdir "$ac_dir"
ac_dir_suffix="/`echo $ac_dir|sed 's%^\./%%'`"
# A "../" for each directory in $ac_dir_suffix.
ac_dots=`echo $ac_dir_suffix|sed 's%/[^/]*%../%g'`
else
ac_dir_suffix= ac_dots=
fi
case "$ac_given_srcdir" in
.) srcdir=.
if test -z "$ac_dots"; then top_srcdir=.
else top_srcdir=`echo $ac_dots|sed 's%/$%%'`; fi ;;
/*) srcdir="$ac_given_srcdir$ac_dir_suffix"; top_srcdir="$ac_given_srcdir" ;;
*) # Relative path.
srcdir="$ac_dots$ac_given_srcdir$ac_dir_suffix"
top_srcdir="$ac_dots$ac_given_srcdir" ;;
esac
echo creating "$ac_file"
rm -f "$ac_file"
configure_input="Generated automatically from `echo $ac_file_in|sed 's%.*/%%'` by configure."
case "$ac_file" in
*Makefile*) ac_comsub="1i\\
# $configure_input" ;;
*) ac_comsub= ;;
esac
sed -e "$ac_comsub
s%@configure_input@%$configure_input%g
s%@srcdir@%$srcdir%g
s%@top_srcdir@%$top_srcdir%g
" -f conftest.subs $ac_given_srcdir/$ac_file_in > $ac_file
fi; done
rm -f conftest.subs
# These sed commands are passed to sed as "A NAME B NAME C VALUE D", where
# NAME is the cpp macro being defined and VALUE is the value it is being given.
#
# ac_d sets the value in "#define NAME VALUE" lines.
ac_dA='s%^\([ ]*\)#\([ ]*define[ ][ ]*\)'
ac_dB='\([ ][ ]*\)[^ ]*%\1#\2'
ac_dC='\3'
ac_dD='%g'
# ac_u turns "#undef NAME" with trailing blanks into "#define NAME VALUE".
ac_uA='s%^\([ ]*\)#\([ ]*\)undef\([ ][ ]*\)'
ac_uB='\([ ]\)%\1#\2define\3'
ac_uC=' '
ac_uD='\4%g'
# ac_e turns "#undef NAME" without trailing blanks into "#define NAME VALUE".
ac_eA='s%^\([ ]*\)#\([ ]*\)undef\([ ][ ]*\)'
ac_eB='$%\1#\2define\3'
ac_eC=' '
ac_eD='%g'
CONFIG_HEADERS=${CONFIG_HEADERS-"config/scl_cf.h"}
for ac_file in .. $CONFIG_HEADERS; do if test "x$ac_file" != x..; then
# Support "outfile[:infile]", defaulting infile="outfile.in".
case "$ac_file" in
*:*) ac_file_in=`echo "$ac_file"|sed 's%.*:%%'`
ac_file=`echo "$ac_file"|sed 's%:.*%%'` ;;
*) ac_file_in="${ac_file}.in" ;;
esac
echo creating $ac_file
rm -f conftest.frag conftest.in conftest.out
cp $ac_given_srcdir/$ac_file_in conftest.in
cat > conftest.frag <<CEOF
${ac_dA}HAVE_DIRENT_H${ac_dB}HAVE_DIRENT_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_DIRENT_H${ac_uB}HAVE_DIRENT_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_DIRENT_H${ac_eB}HAVE_DIRENT_H${ac_eC}1${ac_eD}
${ac_dA}STDC_HEADERS${ac_dB}STDC_HEADERS${ac_dC}1${ac_dD}
${ac_uA}STDC_HEADERS${ac_uB}STDC_HEADERS${ac_uC}1${ac_uD}
${ac_eA}STDC_HEADERS${ac_eB}STDC_HEADERS${ac_eC}1${ac_eD}
${ac_dA}HAVE_STRING_H${ac_dB}HAVE_STRING_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_STRING_H${ac_uB}HAVE_STRING_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_STRING_H${ac_eB}HAVE_STRING_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_MEMORY_H${ac_dB}HAVE_MEMORY_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_MEMORY_H${ac_uB}HAVE_MEMORY_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_MEMORY_H${ac_eB}HAVE_MEMORY_H${ac_eC}1${ac_eD}
CEOF
sed -f conftest.frag conftest.in > conftest.out
rm -f conftest.in
mv conftest.out conftest.in
cat > conftest.frag <<CEOF
${ac_dA}HAVE_UNISTD_H${ac_dB}HAVE_UNISTD_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_UNISTD_H${ac_uB}HAVE_UNISTD_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_UNISTD_H${ac_eB}HAVE_UNISTD_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_SYS_STAT_H${ac_dB}HAVE_SYS_STAT_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_SYS_STAT_H${ac_uB}HAVE_SYS_STAT_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_SYS_STAT_H${ac_eB}HAVE_SYS_STAT_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_DIRENT_H${ac_dB}HAVE_DIRENT_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_DIRENT_H${ac_uB}HAVE_DIRENT_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_DIRENT_H${ac_eB}HAVE_DIRENT_H${ac_eC}1${ac_eD}
${ac_dA}HAVE_STDARG_H${ac_dB}HAVE_STDARG_H${ac_dC}1${ac_dD}
${ac_uA}HAVE_STDARG_H${ac_uB}HAVE_STDARG_H${ac_uC}1${ac_uD}
${ac_eA}HAVE_STDARG_H${ac_eB}HAVE_STDARG_H${ac_eC}1${ac_eD}
CEOF
sed -f conftest.frag conftest.in > conftest.out
rm -f conftest.in
mv conftest.out conftest.in
cat > conftest.frag <<CEOF
${ac_dA}HAVE_MEMCPY${ac_dB}HAVE_MEMCPY${ac_dC}1${ac_dD}
${ac_uA}HAVE_MEMCPY${ac_uB}HAVE_MEMCPY${ac_uC}1${ac_uD}
${ac_eA}HAVE_MEMCPY${ac_eB}HAVE_MEMCPY${ac_eC}1${ac_eD}
${ac_dA}HAVE_MEMMOVE${ac_dB}HAVE_MEMMOVE${ac_dC}1${ac_dD}
${ac_uA}HAVE_MEMMOVE${ac_uB}HAVE_MEMMOVE${ac_uC}1${ac_uD}
${ac_eA}HAVE_MEMMOVE${ac_eB}HAVE_MEMMOVE${ac_eC}1${ac_eD}
${ac_dA}HAVE_SYSCONF${ac_dB}HAVE_SYSCONF${ac_dC}1${ac_dD}
${ac_uA}HAVE_SYSCONF${ac_uB}HAVE_SYSCONF${ac_uC}1${ac_uD}
${ac_eA}HAVE_SYSCONF${ac_eB}HAVE_SYSCONF${ac_eC}1${ac_eD}
${ac_dA}HAVE_STRCHR${ac_dB}HAVE_STRCHR${ac_dC}1${ac_dD}
${ac_uA}HAVE_STRCHR${ac_uB}HAVE_STRCHR${ac_uC}1${ac_uD}
${ac_eA}HAVE_STRCHR${ac_eB}HAVE_STRCHR${ac_eC}1${ac_eD}
CEOF
sed -f conftest.frag conftest.in > conftest.out
rm -f conftest.in
mv conftest.out conftest.in
cat > conftest.frag <<CEOF
${ac_dA}HAVE_ABS${ac_dB}HAVE_ABS${ac_dC}1${ac_dD}
${ac_uA}HAVE_ABS${ac_uB}HAVE_ABS${ac_uC}1${ac_uD}
${ac_eA}HAVE_ABS${ac_eB}HAVE_ABS${ac_eC}1${ac_eD}
s%^[ ]*#[ ]*undef[ ][ ]*[a-zA-Z_][a-zA-Z_0-9]*%/* & */%
CEOF
sed -f conftest.frag conftest.in > conftest.out
rm -f conftest.in
mv conftest.out conftest.in
rm -f conftest.frag conftest.h
echo "/* $ac_file. Generated automatically by configure. */" > conftest.h
cat conftest.in >> conftest.h
rm -f conftest.in
if cmp -s $ac_file conftest.h 2>/dev/null; then
echo "$ac_file is unchanged"
rm -f conftest.h
else
rm -f $ac_file
mv conftest.h $ac_file
fi
fi; done
chmod +x config/setup-arch.current ; chmod +x config/sclbuild.current ; chmod +x config/mkProbe.current ; config/setup-arch.current ; config/sclbuild.current
exit 0

672
configure.in
View file

@ -1,672 +0,0 @@
dnl Process this file with autoconf to produce a configure script named
dnl configure.
dnl This configure script must be run from the root SCL directory.
dnl Don't use the cache file. It confuses things since it won't check your
dnl environment variables like CXX, CCC, and CC.
dnl These set the two variables to null.
define([AC_CACHE_LOAD], )
define([AC_CACHE_SAVE], )
AC_INIT(src)
# note when updating version numbers here, also update pkgIndex.in (see
# comments in Makefile)
SCL_MAJOR_VERSION=3
SCL_MINOR_VERSION=1
SCL_MICRO_VERSION=0
SCL_VERSION=$SCL_MAJOR_VERSION.$SCL_MINOR_VERSION
SCL_VERSION_NODOTS=$SCL_MAJOR_VERSION$SCL_MINOR_VERSION
SCL_VERSION_FULL=$SCL_VERSION.$SCL_MICRO_VERSION
VERSION=$SCL_MAJOR_VERSION.$SCL_MINOR_VERSION
# This forced identification should reduce the pain significantly of using
# people's configure output to identify problems. Use echo so they can't turn
# this of.
echo "configuring SCL $SCL_MAJOR_VERSION.$SCL_MINOR_VERSION.$SCL_MICRO_VERSION"
dnl The configure script must be run from the root SCL directory.
dnl This sets the PDES_ROOT macro.
PDES_ROOT=`pwd`
AC_SUBST(PDES_ROOT)
EXAMPLE_NAME="example"
AC_SUBST(EXAMPLE_NAME)
# could change this so that it will conditionally not make the test stuff
MAKE_EXAMPLE_NAME="make -k"
AC_SUBST(MAKE_EXAMPLE_NAME)
MKPROBE_OPTIONS="-i -p"
dnl Require that they give you an arch dir argument using --with-arch={dir}
dnl Set ARCH_ROOT using it. Use ARCH_ROOT to create an arch dir and edit files
AC_ARG_WITH(arch, [ --with-arch - arch directory for SCL (required)],
[
dnl this is what happens if a --with-arch argument is given without a value
if test "$withval" = "yes" ; then
dnl ARCH_ROOT="$(PDES_ROOT)/arch"
echo "No architecture dir specified with --with-arch argument... specify the architecture directory using --with-arch=specify-arch-directory-here"
exit 1
dnl this is what happens if a --with-arch argument is given with a value
else
echo "Specified architecture directory: $withval"
ARCH_ROOT=$withval
fi
AC_SUBST(ARCH_ROOT) ],
dnl this is what happens if no --with-arch argument is given
[echo "No architecture info specified... specify the architecture directory using --with-arch=specify-arch-directory-here"
exit 1
])
AC_MSG_CHECKING([system version])
SUN_ARCH=`uname -s`
the_sys=`uname -s`-`uname -r`
case $the_sys in
SunOS-4*)
dnl DEFINES="-DSUN4"
AC_MSG_RESULT([SUN4])
SUN_ARCH="SUN4"
;;
SunOS-5*)
dnl DEFINES="-DSYSV"
AC_MSG_RESULT([SUN5])
SUN_ARCH="SUN5"
;;
esac
AC_SUBST(SUN_ARCH)
dnl This is so we can do special things for when we run this at NIST
if test `domainname` = cme.nist.gov ; then
NIST=yes
AC_MSG_RESULT(we are at NIST)
else
NIST=no
AC_MSG_RESULT(we are not at NIST)
fi
dnl This sets the variable SET_MAKE to be null or to be MAKE=make. This assures
dnl that make can be called recursively through subdirectories.
AC_SET_MAKE
dnl Check for the gcc C compiler. If found set the environment variable CC
dnl to be gcc. Otherwise set to cc
AC_PROG_CC
dnl See if it found gcc. The first test should work but it seems to have some
dnl problems.
dnl if test $GCC -eq yes ; then
if test $ac_cv_prog_gcc = yes; then
AC_MSG_RESULT()
else
AC_MSG_RESULT(" if you want to use SPARCworks acc under sunos you need to ")
AC_MSG_RESULT(" set the CC variable in ${ARCH_ROOT}/make_rules")
fi
dnl look for whatever AC_PROG_CC found and replace with complete path
dnl AC_MSG_RESULT(CC is $CC)
AC_MSG_RESULT(Replacing $CC with it's complete path)
AC_PROGRAM_PATH(CC_PATH, $CC,$CC)
CC=$CC_PATH
AC_SUBST(CC)
dnl Determine the C++ compiler to use. Set to the environment variable CXX or
dnl CCC in that order. Otherwise search for c++, g++, gcc, CC in that order.
dnl Sets the make variable CXX.
AC_PROG_CXX
AC_HEADER_DIRENT
AC_STDC_HEADERS
AC_HAVE_HEADERS(string.h memory.h)
AC_HAVE_HEADERS(unistd.h)
AC_HAVE_HEADERS(sysent.h)
AC_CHECK_HEADER(sys/stat.h, AC_DEFINE(HAVE_SYS_STAT_H))
AC_CHECK_HEADER(stat.h, AC_DEFINE(HAVE_STAT_H))
AC_CHECK_HEADER(dirent.h, AC_DEFINE(HAVE_DIRENT_H))
AC_CHECK_HEADER(sys/ndir.h, AC_DEFINE(HAVE_SYS_NDIR_H))
AC_CHECK_HEADER(sys/dir.h, AC_DEFINE(HAVE_SYS_DIR_H))
AC_CHECK_HEADER(ndir.h, AC_DEFINE(HAVE_NDIR_H))
AC_CHECK_HEADER(stdarg.h, AC_DEFINE(HAVE_STDARG_H))
AC_CHECK_FUNC(memcpy, AC_DEFINE(HAVE_MEMCPY))
AC_CHECK_FUNC(memmove, AC_DEFINE(HAVE_MEMMOVE))
AC_CHECK_FUNC(sysconf, AC_DEFINE(HAVE_SYSCONF))
AC_CHECK_FUNC(strchr, AC_DEFINE(HAVE_STRCHR))
AC_CHECK_FUNC(abs, AC_DEFINE(HAVE_ABS))
dnl Look for whatever AC_PROG_CXX found and replace with complete path
dnl AC_MSG_RESULT(CXX is $CXX)
AC_MSG_RESULT(Replacing $CXX with complete path)
AC_PROGRAM_PATH(CXX_PATH, $CXX,$CXX)
CXX=$CXX_PATH
AC_SUBST(CXX)
AC_PROG_RANLIB
case $RANLIB in
*ranlib*)
;;
*)
echo "replacing ranlib with echo for use with make since ranlib is missing"
RANLIB="echo"
AC_SUBST(RANLIB)
;;
esac
AC_MSG_RESULT(RANLIB is $RANLIB)
dnl Check for flex then lex. Set the make variable LEX to the result.
AC_PROG_LEX
AC_MSG_RESULT(LEX is $LEX)
USINGLEX="no"
case $LEX in
*flex*)
USINGLEX="no"
;;
*lex*)
USINGLEX="yes"
;;
esac
dnl Look for whatever AC_PROG_LEX found and replace with complete path
dnl Set LEX_PATH to the complete path for $LEX
AC_PROGRAM_PATH(LEX_PATH, $LEX,$LEX)
DOLLAR=$
if test "$USINGLEX" = "yes" ; then
SCANNER=LEX
dnl This variable still needs to substituted with something
FLEX=flex
LC_ONEA=" $DOLLAR(LEX) $DOLLAR(LEXFLAGS) $DOLLAR< > $DOLLAR*.lex"
#LC_ONEB="*.lex.c"
LC_ONEB=".c"
LC_TWOA=" $DOLLAR(UTIL)/uniquify_lex $DOLLAR*"
LC_TWOB=" "
LO_ONEA=" $DOLLAR(LEX) $DOLLAR(LEXFLAGS) $DOLLAR< > $DOLLAR*"
LO_ONEB=".c"
LO_TWOA=" $DOLLAR(UTIL)/uniquify_lex $DOLLAR*"
LO_TWOB=" "
LO_THREEA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) -c $DOLLAR*"
LO_THREEB=".c"
LOP_ONEA=" $DOLLAR(LEX) $DOLLAR(LEXFLAGS) $DOLLAR< > $DOLLAR"
LOP_ONEB="*.c"
LOP_TWOA=" $DOLLAR(UTIL)/uniquify_lex $DOLLAR"
LOP_TWOB="*"
LOP_THREEA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) $DOLLAR(PROFILE) -c $DOLLAR"
LOP_THREEB="*.c -o $DOLLAR"
LOP_THREEC="@"
else
SCANNER=FLEX
FLEX=$LEX_PATH
LC_ONEA=" $DOLLAR(FLEX) $DOLLAR(FLEXFLAGS) $DOLLAR< > $DOLLAR*.flex"
#LC_ONEB="*.flex.c"
LC_ONEB=".c"
LC_TWOA=" $DOLLAR(UTIL)/uniquify_flex $DOLLAR*"
LC_TWOB=" "
LO_ONEA=" $DOLLAR(FLEX) $DOLLAR(FLEXFLAGS) $DOLLAR< > $DOLLAR*.flex"
LO_ONEB=".c"
LO_TWOA=" $DOLLAR(UTIL)/uniquify_flex $DOLLAR*"
LO_TWOB=" "
LO_THREEA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) -c $DOLLAR*"
LO_THREEB=".c"
LOP_ONEA=" $DOLLAR(FLEX) $DOLLAR(FLEXFLAGS) $DOLLAR< > $DOLLAR"
LOP_ONEB="*.c"
LOP_TWOA=" $DOLLAR(UTIL)/uniquify_flex $DOLLAR"
LOP_TWOB="*"
LOP_THREEA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) $DOLLAR(PROFILE) -c $DOLLAR"
LOP_THREEB="*.c -o $DOLLAR"
LOP_THREEC="@"
fi
AC_MSG_RESULT(Replacing $LEX with it's complete path $LEX_PATH)
LEX=$LEX_PATH
AC_SUBST(LEX)
AC_SUBST(FLEX)
AC_SUBST(SCANNER)
AC_SUBST(LC_ONEA)
AC_SUBST(LC_ONEB)
AC_SUBST(LC_TWOA)
AC_SUBST(LC_TWOB)
AC_SUBST(LO_ONEA)
AC_SUBST(LO_ONEB)
AC_SUBST(LO_TWOA)
AC_SUBST(LO_TWOB)
AC_SUBST(LO_THREEA)
AC_SUBST(LO_THREEB)
AC_SUBST(LOP_ONEA)
AC_SUBST(LOP_ONEB)
AC_SUBST(LOP_TWOA)
AC_SUBST(LOP_TWOB)
AC_SUBST(LOP_THREEA)
AC_SUBST(LOP_THREEB)
AC_SUBST(LOP_THREEC)
dnl Check for bison, byacc, yacc in that order.
dnl Set the make variable YACC to the result (it does it again below).
AC_PROG_YACC
AC_MSG_RESULT(YACC is $YACC)
USINGYACC="yes"
YACC_PATH=$YACC
BISON="bison"
case $YACC in
*yacc*)
USINGYACC="yes"
dnl Look for whatever AC_PROG_YACC found and replace with complete path
dnl Set YACC_PATH to the complete path for $YACC
AC_PROGRAM_PATH(YACC_PATH, $YACC,$YACC)
;;
*bin*)
dnl assume (since it didn't find yacc or byacc) that it
dnl is using bison with a path which means that
dnl configure didn't make it "bison -y"
USINGYACC="no"
dnl Look for whatever AC_PROG_YACC found and replace with complete path
dnl Set YACC_PATH to the complete path for $YACC
AC_PROGRAM_PATH(YACC_PATH, $YACC,$YACC)
BISON=$YACC_PATH
;;
*bison*)
USINGYACC="no"
dnl Assume that autoconf has replaced $YACC with bison -y
dnl Don't use bison -y in the AC_PROGRAM_PATH macro.
dnl Look for whatever AC_PROG_YACC found and replace with complete path
dnl Set YACC_PATH to the complete path for bison
AC_PROGRAM_PATH(YACC_PATH, bison,$YACC)
YACC_PATH="$YACC_PATH -y"
BISON=$YACC_PATH
;;
esac
AC_MSG_RESULT(Replacing $YACC with it's complete path $YACC_PATH)
YACC=$YACC_PATH
dnl Set the make variable YACC to the $YACC.
AC_SUBST(YACC)
dnl Set the make variable BISON to the $BISON.
AC_SUBST(BISON)
if test "$USINGYACC" = "yes" ; then
YC_ONEA=" $DOLLAR(YACC) $DOLLAR(YACCFLAGS) $DOLLAR<"
YC_ONEB=" "
YC_TWO=" $DOLLAR(UTIL)/yacctokens.sh"
YC_THREEA=" mv y.tab.c $DOLLAR"
YC_THREEB="*.tab.c"
YC_FOURA=" mv y.tab.h $DOLLAR"
YC_FOURB="*.tab.h"
YC_FIVEA=" $DOLLAR(UTIL)/uniquify_yacc $DOLLAR"
YC_FIVEB="*"
YC_SIXA=" $DOLLAR(BISONTOKENS) $DOLLAR"
YC_SIXB="*"
YC_SEVENA="#"
YC_SEVENB="#"
YC_EIGHTA="#"
YC_EIGHTB="#"
YO_ONEA=" $DOLLAR(YACC) $DOLLAR(YACCFLAGS) $DOLLAR<"
YO_ONEB=" "
YO_TWOA=" mv y.tab.c $DOLLAR"
YO_TWOB="*.tab.c"
YO_THREEA=" mv y.tab.h $DOLLAR"
YO_THREEB="*.tab.h"
YO_FOURA=" $DOLLAR(UTIL)/uniquify_yacc $DOLLAR"
YO_FOURB="*"
YO_FIVEA=" $DOLLAR(BISONTOKENS) $DOLLAR"
YO_FIVEB="*"
YO_SIXA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) -c $DOLLAR"
YO_SIXB="*.c"
YOP_ONEA=" $DOLLAR(YACC) $DOLLAR(YACCFLAGS) $DOLLAR<"
YOP_ONEB=" "
YOP_TWOA=" $DOLLAR(UTIL)/uniquify_yacc $DOLLAR"
YOP_TWOB="*"
YOP_THREEA=" $DOLLAR(BISONTOKENS) $DOLLAR"
YOP_THREEB="*"
YOP_FOURA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) $DOLLAR(PROFILE) -c $DOLLAR"
YOP_FOURB="*.c -o $DOLLAR"
YOP_FOURC="@"
else
YC_ONEA=" $DOLLAR(YACC) $DOLLAR(YACCFLAGS) -o $DOLLAR"
YC_ONEB="*.tab.c $DOLLAR<"
YC_TWO="# sed barf's on slashes, so expand them out here"
YC_THREEA=" cp $DOLLAR(UTIL)/bison.errors bison.sub"
YC_THREEB=" "
YC_FOURA=" cat $DOLLAR"
YC_FOURB="*.tab.c | sed -e '/yyerror(\"parse error\");/r bison.sub' -e '/yyerror(\"parse error\");/d' > tmp.c"
YC_FIVEA=" rm bison.sub"
YC_FIVEB=" "
YC_SIXA=" mv tmp.c $DOLLAR"
YC_SIXB="*.tab.c"
YC_SEVENA=" $DOLLAR(UTIL)/uniquify_yacc $DOLLAR"
YC_SEVENB="*"
YC_EIGHTA=" $DOLLAR(BISONTOKENS) $DOLLAR"
YC_EIGHTB="*"
YO_ONEA=" $DOLLAR(BISON) $DOLLAR(YACCFLAGS) -o $DOLLAR"
YO_ONEB="*.tab.c $DOLLAR<"
YO_TWOA=" $DOLLAR(UTIL)/uniquify_yacc $DOLLAR"
YO_TWOB="*"
YO_THREEA=" $DOLLAR(BISONTOKENS) $DOLLAR"
YO_THREEB="*"
YO_FOURA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) -c $DOLLAR"
YO_FOURB="*.c"
YO_FIVEA="#"
YO_FIVEB="#"
YO_SIXA="#"
YO_SIXB="#"
YOP_ONEA=" $DOLLAR(BISON) $DOLLAR(YACCFLAGS) -o $DOLLAR"
YOP_ONEB="*.c $DOLLAR<"
YOP_TWOA=" $DOLLAR(UTIL)/uniquify_yacc $DOLLAR"
YOP_TWOB="*"
YOP_THREEA=" $DOLLAR(BISONTOKENS) $DOLLAR"
YOP_THREEB="*"
YOP_FOURA=" $DOLLAR(CC) $DOLLAR(CCFLAGS) $DOLLAR(PROFILE) -c $DOLLAR"
YOP_FOURB="*.c -o $DOLLAR"
YOP_FOURC="@"
fi
AC_SUBST(YC_ONEA)
AC_SUBST(YC_ONEB)
AC_SUBST(YC_TWO)
AC_SUBST(YC_THREEA)
AC_SUBST(YC_THREEB)
AC_SUBST(YC_FOURA)
AC_SUBST(YC_FOURB)
AC_SUBST(YC_FIVEA)
AC_SUBST(YC_FIVEB)
AC_SUBST(YC_SIXA)
AC_SUBST(YC_SIXB)
AC_SUBST(YC_SEVENA)
AC_SUBST(YC_SEVENB)
AC_SUBST(YC_EIGHTA)
AC_SUBST(YC_EIGHTB)
AC_SUBST(YO_ONEA)
AC_SUBST(YO_ONEB)
AC_SUBST(YO_TWOA)
AC_SUBST(YO_TWOB)
AC_SUBST(YO_THREEA)
AC_SUBST(YO_THREEB)
AC_SUBST(YO_FOURA)
AC_SUBST(YO_FOURB)
AC_SUBST(YO_FIVEA)
AC_SUBST(YO_FIVEB)
AC_SUBST(YO_SIXA)
AC_SUBST(YO_SIXB)
AC_SUBST(YOP_ONEA)
AC_SUBST(YOP_ONEB)
AC_SUBST(YOP_TWOA)
AC_SUBST(YOP_TWOB)
AC_SUBST(YOP_THREEA)
AC_SUBST(YOP_THREEB)
AC_SUBST(YOP_FOURA)
AC_SUBST(YOP_FOURB)
AC_SUBST(YOP_FOURC)
SCL_DEFS=" "
dnl SCL_DEFS="-D_SUNCPLUSPLUS"
dnl AC_MSG_RESULT(SCL_DEFS is $SCL_DEFS)
dnl SCL_DEFS="${SCL_DEFS} -D_HI_"
dnl AC_MSG_RESULT(SCL_DEFS is $SCL_DEFS)
AC_SUBST(SCL_DEFS)
dnl This will replace the following variables with defaults if
dnl --with-iv or --without-iv is not used.
IV_ROOT_DIR=" "
MAKE_IVFASD=" "
MAKE_PROBEUI=" "
EXECUTABLE_MKPROBE=" "
AC_SUBST(IV_ROOT_DIR)
AC_SUBST(MAKE_IVFASD)
AC_SUBST(MAKE_PROBEUI)
AC_SUBST(EXECUTABLE_MKPROBE)
AC_ARG_WITH(iv, [ --with-iv - root directory for InterViews],
[
if test "$withval" = "yes" || test "$withval" = "no" ; then
AC_MSG_WARN("No InterViews root dir specified with --with-iv argument... specify the IV root directory using --with-iv=specify-iv-root-directory-here")
else
AC_MSG_RESULT("Specified root directory for InterViews: $withval")
IV_ROOT_DIR=$withval
MAKE_IVFASD="make -k ivfasd"
MAKE_PROBEUI="make -k probe-ui"
MKPROBE_OPTIONS="-i"
dnl EXECUTABLE_MKPROBE="chmod 775 mkProbe.$ARCH_ROOT"
EXECUTABLE_MKPROBE="chmod 775 mkProbe.current"
AC_SUBST(IV_ROOT_DIR)
AC_SUBST(MAKE_IVFASD)
AC_SUBST(MAKE_PROBEUI)
AC_SUBST(EXECUTABLE_MKPROBE)
fi
],
[
AC_MSG_WARN("No InterViews info specified... to use InterViews specify the IV root directory using --with-iv=specify-iv-root-directory-here")
])
dnl This will replace the following variables with defaults if
dnl --with-iv-includes or --without-iv-includes is not used.
IV_INCLUDE_DIR="$(IVROOT)/installed/include"
AC_SUBST(IV_INCLUDE_DIR)
AC_ARG_WITH(iv-includes, [ --with-iv-includes - directory for InterViews includes],
[
if test "$withval" = "yes" || test "$withval" = "no" ; then
AC_MSG_WARN("No InterViews include dir specified with --with-iv-includes... using the default include dir")
dnl IV_INCLUDE_DIR="$(IVROOT)/installed/include"
dnl AC_SUBST(IV_INCLUDE_DIR)
else
AC_MSG_RESULT("Specified include directory for InterViews: $withval")
IV_INCLUDE_DIR=$withval
AC_SUBST(IV_INCLUDE_DIR)
fi
],
dnl action if called without either option --with-iv-includes or --without-iv-includes
)
dnl This will replace the following variables with defaults if
dnl --with-iv-lib or --without-iv-lib is not used.
INTERVIEWS_LIB_DIR="$(IVROOT)/installed/lib/${SUN_ARCH}"
AC_SUBST(INTERVIEWS_LIB_DIR)
AC_ARG_WITH(iv-lib, [ --with-iv-lib - directory for InterViews library],
[
if test "$withval" = "yes" || test "$withval" = "no" ; then
AC_MSG_WARN("No InterViews lib dir specified with --with-iv-lib... using the default dir")
else
AC_MSG_RESULT("Specified lib directory for InterViews: $withval")
INTERVIEWS_LIB_DIR=$withval
AC_SUBST(INTERVIEWS_LIB_DIR)
fi
],
dnl action if called without either option --with-iv-lib or --without-iv-lib
)
AC_SUBST(MKPROBE_OPTIONS)
dnl This will replace the following variables with defaults if
dnl --with-ostore or --without-ostore is not used.
OS_FLAGS=" "
AC_SUBST(OS_FLAGS)
OS_ROOTDIR=" "
OS_INC_DIR=" "
LIBOSC_LD=" "
LIBOSTHR_LD=" "
OS_LIB_DIR=" "
OS_LIBS=" "
AC_SUBST(OS_ROOTDIR)
AC_SUBST(OS_INC_DIR)
AC_SUBST(LIBOSC_LD)
AC_SUBST(LIBOSTHR_LD)
AC_SUBST(OS_LIB_DIR)
AC_SUBST(OS_LIBS)
AC_ARG_WITH(ostore, [ --with-ostore - root directory for ObjectStore],
[
if test "$withval" = "yes" || test "$withval" = "no" ; then
AC_MSG_WARN("No ObjectStore root dir specified with --with-ostore... ")
else
AC_MSG_RESULT("Specified root directory for ObjectStore: $withval")
OS_FLAGS="$(TFLAGS) -D__OSTORE__"
AC_SUBST(OS_FLAGS)
OS_ROOTDIR=$withval
OS_INC_DIR="-I$(OS_ROOTDIR)/include"
LIBOSC_LD=" "
LIBOSTHR_LD="-losthr"
OS_LIB_DIR="-L$(OS_ROOTDIR)/lib"
OS_LIBS="-loscol -los $(LIBOSTHR_LD) $(LIBOSC_LD)"
AC_SUBST(OS_ROOTDIR)
AC_SUBST(OS_INC_DIR)
AC_SUBST(LIBOSC_LD)
AC_SUBST(LIBOSTHR_LD)
AC_SUBST(OS_LIB_DIR)
AC_SUBST(OS_LIBS)
fi
],
dnl action if called without either option --with-ostore or --without-ostore
)
AC_ARG_WITH(ostore-includes, [ --with-ostore-includes - directory for ObjectStore includes],
[
if test "$withval" = "yes" || test "$withval" = "no" ; then
AC_MSG_WARN("No ObjectStore include dir specified with --with-ostore-includes... ")
else
AC_MSG_RESULT("Specified include directory for ObjectStore: $withval")
OS_INC_DIR="-I$withval"
AC_SUBST(OS_INC_DIR)
fi
],
dnl action if called without either option --with-ostore-includes or --without-ostore-includes
)
AC_ARG_WITH(ostore-lib, [ --with-ostore-lib - lib directory for ObjectStore],
[
if test "$withval" = "yes" || test "$withval" = "no" ; then
AC_MSG_WARN("No ObjectStore lib dir specified with --with-ostore-lib... ")
else
AC_MSG_RESULT("Specified lib directory for ObjectStore: $withval")
OS_LIB_DIR="-L$withval"
AC_SUBST(OS_LIB_DIR)
fi
],
dnl action if called without either option --with-ostore-lib or --without-ostore-lib
)
CP_SCLPREFIXES="cp sclprefixes.h.noOrbixOstore sclprefixes.h"
AC_SUBST(CP_SCLPREFIXES)
MAKE_SDAIORBIX=" "
AC_SUBST(MAKE_SDAIORBIX)
ORBIX_INCS=" "
ORBIX_FLAGS=" "
ORBIX_MK_FILE=" "
AC_SUBST(ORBIX_INCS)
AC_SUBST(ORBIX_FLAGS)
AC_SUBST(ORBIX_MK_FILE)
AC_ARG_WITH(orbixmk, [ --with-orbixmk - Orbix .mk make rules/macros file],
[
if test "$withval" = "yes" || test "$withval" = "no" ; then
AC_MSG_WARN("No Orbix .mk file specified with --with-orbixmk... ")
if test $NIST = "yes" && test "$withval" = "yes" ; then
AC_MSG_RESULT("Assigning NIST defaults for orbix options")
CP_SCLPREFIXES="cp sclprefixes.h.OrbixOstore sclprefixes.h"
AC_SUBST(CP_SCLPREFIXES)
MAKE_SDAIORBIX="make -k sdaiOrbix"
AC_SUBST(MAKE_SDAIORBIX)
ORBIX_FLAGS="-DPART26 -DNO_BOOLS_LOGS -D__CORBA__ -DNO_P26_NAMESPACE"
ORBIX_INCS="-I$(SCL_IDL_INCDIR) -I$(ORBIX_INCDIR)"
ORBIX_MK_FILE="include /depot/orbix-2.0/arch.sunos5/corba2/demos/orbixmtsol2s4.mk"
AC_SUBST(ORBIX_INCS)
AC_SUBST(ORBIX_FLAGS)
AC_SUBST(ORBIX_MK_FILE)
fi
else
AC_MSG_RESULT("Specified Orbix .mk file to be included in make_rules: $withval")
CP_SCLPREFIXES="cp sclprefixes.h.OrbixOstore sclprefixes.h"
AC_SUBST(CP_SCLPREFIXES)
MAKE_SDAIORBIX="make -k sdaiOrbix"
AC_SUBST(MAKE_SDAIORBIX)
ORBIX_MK_FILE="include $withval"
ORBIX_FLAGS="-DPART26 -DNO_BOOLS_LOGS -D__CORBA__ -DNO_P26_NAMESPACE"
ORBIX_INCS="-I$(SCL_IDL_INCDIR) -I$(ORBIX_INCDIR)"
AC_SUBST(ORBIX_INCS)
AC_SUBST(ORBIX_FLAGS)
AC_SUBST(ORBIX_MK_FILE)
fi
],
dnl action if called without either option --with-orbixmk or --without-orbixmk
)
AC_ARG_WITH(logging, [ --with-logging - turn on SCL logging],
[
AC_MSG_RESULT("Turn on SCL logging: $withval")
if test "$withval" = "yes" ; then
SCL_DEFS="$SCL_DEFS -DSCL_LOGGING"
AC_SUBST(SCL_DEFS)
fi
],
dnl action if called without either option --with-logging or --without-logging
)
echo ARCH_ROOT is: $ARCH_ROOT
AC_CONFIG_HEADER(config/scl_cf.h)
AC_OUTPUT(config/sclbuild.current config/mkProbe.current config/setup-arch.current arch_template/make_rules arch_template/testbuild/schema-loc arch_template/ofiles/sdaiOrbix/corbaIncludes.h arch_template/Probes/template-schema/Makefile.personal src/express/mkrules , [chmod +x config/setup-arch.current ; chmod +x config/sclbuild.current ; chmod +x config/mkProbe.current ; config/setup-arch.current ; config/sclbuild.current])
dnl if test $SUN_ARCH = sun4; then
dnl AC_MSG_RESULT(sun4)
dnl AC_OUTPUT(arch_template/make_rules.sun2 ,cd arch_template; rm -f make_rules ; ln -s make_rules.sun2 make_rules)
dnl else
dnl AC_MSG_RESULT(sun5)
dnl AC_OUTPUT(arch_template/make_rules.sun ,cd arch_template ; rm -f make_rules ; ln -s make_rules.sun make_rules)
dnl fi
dnl ///////////////////////////////////////////////////////////////
dnl ACC=cc
dnl AC_LANG_C
dnl AC_LANG_CPLUSPLUS

369
whatsnew.2-1.txt
View file

@ -1,369 +0,0 @@
What's new in the STEP Class Library and Data Probe release 2.1
June 1995
This release of the STEP Class Library (SCL), fedex_plus code
generator, and Data Probe also contains the latest releases of the
fedex syntax and semantic checker, the NIST Express Toolkit (also new
on SOLIS as of June 12, 1995), and the Express Pretty Printer Toolkit.
The NIST Express Toolkit and fedex have been updated to handle the IS
version of Express and various problems have been fixed as a result of
pre-validation conformance testing. Following is an overview of
what's new in the STEP Class Library (and hence fedex_plus) and the
Data Probe.
--------------------
*Compilers supported:
--------------------
The SCL and Data Probe now compiles with gnu C++ v2.5.8, v2.6, and
Sun C++ v3.0.1. The SCL also compiles with ppCC, the pre-processor of
the Open OODB from TI.
-------------------
*Complex Instances:
-------------------
The SCL now supports instantiation of complex instances via a class
called STEPcomplex. The SCL supports reading and writing of complex
instances from/to Part 21 and Working files using the external mapping
specified in Part 21.
Complex instances are created by calling the constructor for
STEPcomplex with a list of entity name strings. The combination of
entity names that are passed in to become part of the complex instance
are not validated to determine if they are a legal set of entities
with regard to the inheritance structure specified in Express.
Attributes within each of the represented entities are validated as
usual.
An entity hierarchy with triangle and circle both inheriting from
shape with andor inheritance would allow creation of a
circle-shape-triangle entity. Here is an example of how such an
object could be created.
SCLstring *entNmArr[64]; // array of entity type names
int fileid = 1;
Registry *registry = new Registry(SchemaInit);
entNmArr[0] = new SCLstring("shape");
entNmArr[1] = new SCLstring("triangle");
entNmArr[2] = new SCLstring("circle");
entNmArr[3] = 0;
STEPentity * obj = new STEPcomplex(&_reg, (const SCLstring **)entNmArr,
fileid);
In the same manner the toolkit would allow a user to create a
circle-shape-triangle-color entity even if it was not valid given the
Express.
The complex instances implementation has a late bound flavor. The
instances do not have code generated implementing attribute access
functions with names matching the name of the attribute. This method
of access, normally associated with an early binding, is available for
non-complex instances and is partially available for instances
involving multiple inheritance. The complex entity instance's
attributes are accessible through the STEPattribute class in a manner
similar to the non-complex instances.
The Data Probe reads and writes complex instances from/to Part 21 and
Working files but supports very limited editing of complex instances.
----------------------
*Multiple Inheritance:
----------------------
The SCL offers two choices to users in handling multiple inheritance.
These include the method offered by SCL in previous releases and the
current method. The current method handles attributes inherited from
all parents. It does not correctly handle multiple inheritance where
an entity has more than one path through parents to a common ancestor.
One could imagine this case as a diamond shaped inheritance structure.
When this case of multiple inheritance is encountered attributes are
duplicated. This case of multiple inheritance may possibly be
avoided by modifying the EXPRESS schema by breaking some links in the
inheritance hierarchy. This will not have an adverse affect on the
implemementation. The user may choose to use the current or previous
method of handling multiple inheritance. The current method is the
default behavior. The previous method is obtained by supplying the
-s (or -S) option with the fedex_plus code generator or the mkProbe
script.
When the fedex_plus code generator is generating the C++ class library
representation of a schema, it outputs information calling attention
to the cases of multiple inheritance.
The previous method of handling multiple inheritance:
This method of handling multiple inheritance is useful where
attributes are inherited from only one parent. It does not allow an
entity instance to be casted in C++ to a class representing
non-implemented parents. These multiply inherited instances are
created in the same manner as non-multiply inherited, non-complex
instances.
For each entity that has multiple parents the first parent that
contains or inherits attributes is used in the inheritance hierarchy
for the C++ class representing the entity. In each case of multiple
inheritance the parents are searched for attributes in the same order
as they were specified for the entity in Express. Once attributes
have been found associated with one parent, attributes from other
parents are ignored. All attributes handled have access functions.
The current method of handling multiple inheritance:
Multiply inherited instances are created in the same manner as
non-multiply inherited, non-complex instances. These include calling
any of the following functions:
1. the constructor of the entity class.
2. Registry::ObjCreate() with the name of the entity as a string argument.
3. EntityDescriptor::NewSTEPentity() from the dictionary entry
associated with the entity to be created.
a c e
| | | This hierarchy modeled in Express turns into
b d f the data structures pictured below.
\ | /
\ | / h
\|/ /
g -
Each STEPentity also has a pointer back to g's STEPentity.
STEPentity STEPentity STEPentity
-------------------- -------------------- --------------------
| - attribute list | | - attribute list | | - attribute list |
| for a, b, c, d,| | for c and d | | for e and f |
| e, f, h, and g | | (in that order)| | (in that order)|
| (in that order)| | | | |
| - pointer to | | - pointer to | | - pointer to |
| STEPentity ----+--->| STEPentity ----+--->| STEPentity ----+----
| - pointer to | | - pointer to | | - pointer to | |
| dictionary | | dictionary | | dictionary | |
| entry for g | | entry for d | | entry for f | |
-------------------- -------------------- -------------------- |
| | | |
a c e |
---------------------- ---------------------- ---------------------- |
| - attributes for a | | - attributes for c | | - attributes for e | |
| - access functions | | - access functions | | - access functions | |
| for a | | for c | | for e | |
---------------------- ---------------------- ---------------------- |
| | | |
b d f |
---------------------- ---------------------- ---------------------- |
| - attributes for b | | - attributes for d | | - attributes for f | |
| - access functions | | - access functions | | - access functions | |
| for b | | for d | | for f | |
---------------------- ---------------------- ---------------------- |
| |
g |
---------------------- |
| - attributes for g | |
| - access functions | |
| for g | |
---------------------- |
|
STEPentity <-----------
--------------------
| - attribute list |
| for h |
| - pointer to |
| STEPentity |
| - pointer to |
| dictionary |
| entry for h |
--------------------
|
h
|
----------------------
| - attributes for h |
| - access functions |
| for h |
----------------------
Multiply inherited entities have two early bound access functions
associated with all of the attributes - one for get attribute value
and one for set attribute value. These access functions have the same
name as the attribute. The requirement for use of these access
functions is that they must be called from the appropriate part of
the data structure representing the multiply inherited instance. C's
attribute access functions could be called from a pointer to the C or
D part of the data structures shown above. Functions are supplied for
accessing the appropriate part of the data structure.
a
/ \ An Express schema containing this type of inheritance hierarchy
| | under the current multiple inheritance implementation will cause
b c attributes for 'a' to be duplicated.
| |
\ /
d
The Data Probe fully supports the SCL implementation of multiply
inherited entity instances. Inside a STEP Entity Editor window,
attribute dictionary information is displayed as usual for all
attributes in multiply inherited entity instances. It currently,
however, only displays the first parent encountered each step up the
parent hierarchy when displaying Express dictionary information for
the entity as a result of pressing the Type Information button.
------------------
*Part 21 Comments:
------------------
The SCL now handles comments associated with Part 21 and SCL Working
files. It saves comments preceding an entity instance with the entity
instance that follows. It can handle saving all the comments in the
example below. All the comments would be saved as part of entity
instance #1.
/*comment 1*/ /*cmt 1.5 */
#1/*cmt 2*/=/*cmt 3*/ORGANIZATION/*cmt 4*/( 'hi','foo','bar')/*cmt 5*/;/*cmt6*/
#2=ORGANIZATION('ab','cd','ef');
When writing instance #1 above to a Part 21 or Working file, all
comments that have been saved with the instance will be written out
separately preceding the instance as follows.
/*comment 1*/
/*cmt 1.5 */
/*cmt 2*/
/*cmt 3*/
/*cmt 4*/
/*cmt 5*/
#1=ORGANIZATION('hi','foo','bar');
/*cmt6*/
#2=ORGANIZATION('ab','cd','ef');
Part 21 comments are also read and written for header entity instances.
Part 21 comments are supported in the Data Probe. Comments associated
with an entity appear in the comment field on the STEP Entity Editor
window. The comment (formerly "label") field accepts comments that
will be saved to a Part 21 or Working file and comments that are not.
Comments written as valid Part 21 comments (i.e. enclosed in /* */)
will be saved in files. Non-Part 21 text will only last until the end
of the Data Probe session or until the entity is deleted, whichever
comes first.
---------
*Selects:
---------
The way SCL handles selects for editing and writing part 21 files has
been updated. Here are the new rules.
- If there is only one choice in the select (i.e. a select of one
type), the value for that choice can be entered without qualification.
- If the select is between entities only (and not via nested selects),
the element types are assumed to be unique and values can be entered
as a reference to an entity instance.
- In all other cases the value must be qualified by enclosing the
value in the type of the select item.
- These rules apply to editing in the Data Probe, as well as reading
from and writing to a file.
When editing a select attribute in the Data Probe STEP Entity Editor
window, mouse clicking the edit button offers support for qualifying
the select attribute value. When you click the edit button for a
select attribute, and choose a type from the list, it is applied to
the attribute value field in the entity editor.
If there wasn't a value in the attribute previously, then the field will
contain just the type specifier, e.g., Str1() if Str1 is the type selected.
If a value exists in the field, it is modified to accomodate the new
specifier. This means the following:
o If the value in the field starts with a single-quote ('), it is
assumed to be a string literal, and is completely wrapped in the new
specifier (e.g., 'foobar' --> Str1('foobar') ).
o If the value starts with an open-paren ('('), it is assumed to be an
aggregate literal, and is wrapped in the new specifier as above.
o If the value already has a specified type (e.g., Str1('foo')), things
get interesting. (By the way, containing a specified type is
determined by the existence of an open paren (after the first
character) encountered before end-of-string.) Ordinarily, the
type specifier is replaced by the new type, e.g.,
Str1(.enumval.) --> Enum1(.enumval.).
However, if the new type is a SELECT, then the whole value in the
field is wrapped in the new type specifier, e.g., Str1('foo') -->
Sel1(Str1('foo')) if the new type is Sel1. This is because it is
assumed that the user is qualifying the subtype of the SELECT before
'editing'. A possible future enhancement may check to see if
the field contains a valid select subtype, and if not, do a
replace as in the above Str1->Enum1 example.
If the field entry matches none of these cases, it is just wrapped in the
type specifier... actually, the only real reason for having the string
and aggregate special cases is that they contain (or can contain)
parentheses that would throw off checking for type specifiers...
Validation of all of this still occurs in the editing window as usual,
so if the user chooses something invalid, it is still flagged in the
STEP Entity Editor window.
---------
*Strings:
---------
Strings can now differentiate between a string that does not exist and
a string that has no elements. This may be done with the following
functions in the SCLstring class in scl_string.h:
// returns 1 if _strBuf is a null ptr or if it is an empty string (i.e. "")
int is_null() const;
// returns 1 if _strBuf is a null ptr, and 0 otherwise
int is_undefined() const;
// deletes _strBuf
void set_undefined() ;
// zeroes out space in _strBuf
int set_null() ;
The Data Probe now differentiates between a STRING attribute value
that does not exist and one that exists but contains no characters.
When editing an attribute of type string in a STEP Entity Editor
window, an attribute value containing only a dollar sign indicates that
the string attribute value does not exist. An attribute value
containing only a backslash followed by a dollar sign indicates a
string value of length one containing a dollar sign. The absence of a
value indicates that the string exists but contains no characters.
-------------
*Enumerations:
-------------
The access functions for enumerations now accept the associated C/C++
enumeration value rather than the enumeration class. Implicit calling
of casting functions makes it possible for instances of the
enumeration class still to be passed into the attribute's get
functions and to be assigned the return value of the attribute's put
functions.
--------
*Boolean:
--------
Attributes of type Boolean and aggregate of Boolean were previously
implemented using the Logical and Logicals classes (respectively).
The fedex_plus code generator now generates classes Boolean and
Booleans to implement attributes of type Boolean and aggregate of
Boolean respectively.
--------------------------------
*Public Data Member Name Changes:
--------------------------------
In class STEPentity:
Descriptor is now eDesc
In class STEPattribute:
Descriptor is now aDesc
The name change in STEPentity was to avoid symbol name conflicts of
STEPentity::Descriptor with access functions generated for Express
entity attributes named descriptor. The new name will not be
conflicting with any generated names since the letter case will never
match.

428
whatsnew.3-1.txt
View file

@ -1,428 +0,0 @@
What's New in the STEP Class Library Release 3.1
October 1997
The following is a list of enhancements which are found in the version
3.1 release of the SCL and Data Probe. It assumes you are familiar
with EXPRESS (ISO 10303-11). Familiarity with version 2.1 or higher
is a big plus.
-------------------
Easier Installation
-------------------
We created a script called configure using gnu's autoconf software.
The configure script is used to install the SCL release. Configure
automates the editing of multiple SCL files based on site-specific
information needed for installation. It performs checks against the
software and operating system environment to create a header file used
by SCL to handle commonly known software porting problem areas.
Finally, it builds all the SCL executables, scripts, and libraries.
Configure requires one command line argument specifying a name which
is used to create a directory. Configure installs the architecture and
environment specific SCL executables, scripts, libraries, and object
code is under this directory.
Configure accepts optional command line arguments to install the SCL
for use with optional software packages (like Orbix and/or
ObjectStore) and for use with different compilers on different
operating systems and/or machine architectures. Configure may be
executed several times to create several SCL builds under separate
architecture/environment specific directories. Each of these
directories is based on the same source code directory to minimize
space requirements. This is possible because the SCL source code was
created with preprocessor switches which allows the same source code
to be built for different purposes. Separate builds are also necessary
to use SCL with different C++ compilers since C++ object code is not
compatible between C++ compilers.
-----------------------------------------------------
Alignment with the C++ Binding (ISO 10303-23) to the Standard Data
Access Interface (SDAI, ISO 10303-22)
-----------------------------------------------------
SCL has been better aligned with the C++ binding (ISO 10303-23,
a.k.a. STEP Part 23) to SDAI. This has involved several name changes
for classes implementing base EXPRESS types and application-schema
defined EXPRESS types. The name changes were possible since these
types and classes have been moved to be encapsulated by a namespace
implemented via a struct definition. The namespace has been defined in
a way that offers great flexibility in avoiding name conflict with
other software packages (like X Windows, CORBA implementations, etc)
and your application code. The namespace name is easily changed if
necessary. As a result of adding a namespace a noticeable difference
in SCL use has occurred.
Use of underlying SCL classes and types are now wrapped in macros that
are defined in the file sclprefixes.h. This file is installed under
the arch directory which allows it to be adjusted as necessary for
each SCL software installation. For example, if a compiler or software
package has a problem handling the namespace mechanism via a struct
definition alternate macros can be used from the sclprefixes.h file
bypassing the namespace altogether. If a name conflict occurs when the
namespace is turned off macros can be used that add a name prefix to
SCL types and classes. Use of the macros when using SCL types and
classes is what allows for the flexibility in dealing with problem
areas when using SCL with other software.
An example of a name change and macro use: sdaiString has now become
SCLP23(String) which could translate to SDAI::String or SDAI_String
(depending on whether you use the SDAI namespace or not) or any other
namespace or prefix as is necessary. To change the SDAI namespace name
or prefix name the macro definition for SCLP23() could be changed in
the sclprefixes.h file.
The early bound access functions that are generated by fedex_plus from
EXPRESS defined entities have been updated to the latest version of
Part 23's C++ binding to SDAI. A previous early bound function defined
as "const SdaiLabel Name()" would now be defined according to Part 23 as
"const SdaiLabel name_()". *notice* that application schema defined
types are not yet defined in a namespace. Compatibility with previous
versions of SCL early bound functions has been maintained via the -a
fedex_plus option.
-----------------------------------------------------
SDAI Session Schema objects implemented (model_contents, extents, etc)
-----------------------------------------------------
Several classes and types defined as part of SDAI Part 23's Session
Schema have been implemented (where before they mostly had stub
functions). These have been implemented for use with or without the
ObjectStore object oriented database. Model_contents_<schema_name> is
now being generated by fedex_plus allowing Entity_extents to be
maintained for entities as desired.
-----------------------------------------------------
Object Oriented Database Capability Using ObjectStore
-----------------------------------------------------
SCL has been enhanced to optionally use the object oriented database
ObjectStore from ODI. The INSTALL file describes how to build the SCL
libraries for use with ObjectStore. The SCL libraries built for use
with ObjectStore may then be used to create persistent or transient
SCL objects. The transient objects use the ObjectStore transient
database.
The SCL application, fedex_os, uses an application schema written in
EXPRESS to generate additional code needed for use with ObjectStore.
Fedex_os is used in conjunction with fedex_plus for generating the C++
necessary to implement your application schema.
Although building SCL libraries for use with ObjectStore is
documented, instructions for building your application with SCL
libraries and ObjectStore is as of yet undocumented. The undocumented
steps for building an SCL/ObjectStore application are the steps
required to build any ObjectStore application. A person familiar with
building ObjectStore applications should be able to create a Makefile
able to perform these necessary steps.
A good starting point for creating a Makefile suitable for building an
SCL/ObjectStore application would be the Makefile generated using the
mkProbe script. The configure script (executed with the ObjectStore
options) generates a make_rules file which contains the necessary
Makefile macros for using ObjectStore. The mkProbe generated Makefile
already includes this make_rules file. The Makefile is set up to build
a simple application which uses the appropriate SCL and ObjectStore
libraries. The Makefile rules for building this application could be
used as a starting point for creating Makefile rules to build your own
SCL/ObjectStore application. (The example application code is not set
up to use ObjectStore.) Additional steps would need to be added to run
the ObjectStore schema generator (ossg), link with the additional
application-specific ObjectStore object files, run os_postlink, etc.
-------------------------------------------------------
Use of Orbix with SCL for Developing CORBA Applications
-------------------------------------------------------
SCL has been enhanced to be able to use Orbix for developing SCL
applications for use within the Common Object Request Broker
Architecture (CORBA). CORBA is used to provide an architecture for use
of objects within a distributed environment. Distributed communication
occurs by client applications communicating with servers through
Object Request Brokers (ORBs). Clients may be written to use any
number of programming languages provided the CORBA software vendor
(Orbix in this case) supports the language. We have only tested
clients written using C++. We may soon test JAVA clients.
The SCL application, fedex_idl, is used to create an Interface
Definition Language (IDL) schema from your application's EXPRESS
schema. The generation of IDL schemas by fedex_idl is according to
STEP's Part 26 Interface Definition Language binding to the SDAI. The
Orbix IDL compiler is then used to generate the client and server code
necessary for communication through an Orbix ORB. The SCL application,
fedex_plus, would then be run with the -c option on your application's
EXPRESS schema to generate the server implementation objects required
to build an Orbix server (it uses the TIE approach). You would be
required to write the C++ main() function for the server code.
Although building SCL libraries for use with Orbix is documented,
instructions for building your application with SCL libraries and
Orbix is as of yet undocumented. The undocumented steps for building
an SCL/Orbix application are the steps required to build any Orbix
application. A person familiar with building Orbix applications should
be able to create a Makefile able to perform these necessary steps.
A good starting point for creating a Makefile suitable for building an
SCL/Orbix application would be the Makefile generated using the
mkProbe script. The configure script (executed with the Orbix options)
generates a make_rules file which contains the necessary Makefile
macros for using Orbix. The mkProbe generated Makefile already
includes this make_rules file. The Makefile is set up to build a
simple application which uses the appropriate SCL and Orbix
libraries. The Makefile rules for building this application could be
used as a starting point for creating Makefile rules to build your own
SCL/Orbix application. (The example application code is not set up to
use Orbix.) Additional steps would need to be added to build the
additional server code you would need to write, register the server
with Orbix, build and link with the IDL compiler generated code, etc.
-----------------------------------------------------
Use of Orbix and ObjectStore with SCL
-----------------------------------------------------
SCL has been enhanced to be able to be used with Orbix and ObjectStore
providing a persistent server for use within a distributed CORBA
environment. We have used SCL in this way for two NIST projects: the
National Industrial Information Infrastructure Protocols project and
the National Advanced Manufacturing Testbed Framework project.
Once again, although building the SCL libraries for use with Orbix and
ObjectStore is documented (via installation using the configure
script), instructions for building your application to use Orbix and
ObjectStore is as of yet undocumented. See the previous two sections.
-----------------------
MULTIPLE SCHEMA SUPPORT
-----------------------
A library and Data Probe can now be generated for an EXPRESS file
containing multiple schemas. This is done primarily by dividing the
source code generated by fedex_plus into separate files. Separate
files are generated for each schema contained in the EXPRESS file. In
addition, often schemas are dependent on one another. This will be
the case if the schemas use and reference entities and types from each
other. If, for example, entity X in schema A is a subtype of entity Y
in schema B, X will not be processed until B in schema Y is processed.
Other such cases of interdependence occur if an entity in schema A
contains as an attribute an enumeration or select type defined in
another schema. To address such cases, fedex_plus may process a
schema in multiple passes. At each pass, only the objects in the
schema which are not dependent on not-yet-processed objects in other
schemas are processed. At each successive pass through the schemas as
more and more objects are processed, more and more dependent entities
will become processable. Certain schemas may require three passes or
more in cases of chains of dependence (such as A being a supertype of
B which is a supertype of C, etc.).
For an EXPRESS file with multiple dependent schemas, it is advisable
to organize the file with bottom-up design. Schemas containing the
simpler, building block types and entities should appear first. By
doing so, when fedex_plus begins processing the more complex schemas,
there will be fewer cases in which the parser will encounter not-yet-
defined objects from other schemas. (The objects which are referenced
the most will have already been defined.) This will minimize the
number of times fedex_plus is required to divide output files.
One known case of interdependence which fedex_plus is not able to
support occurs if say select A has select B as an item, and select B
has select A as an item. (This is unsupported even if A and B are in
the same schema.) fedex_plus has no way in which it can generate
compilable source code for the selects because each is dependent on
the other. In addition, this would cause the parser to fall into an
endless loop, so we strongly discourage it. ;-)
------------------------------
USE / REFERENCE CLAUSE SUPPORT
------------------------------
The SCL also partially supports the EXPRESS concepts of USE and
REFERENCE. According to the rules of EXPRESS, schema A may reference
objects from schema B by way of a USE or REFERENCE clause (U/R). Any
object which is not U/R'ed from schema A to B, directly or indirectly,
is not visible to B. The SCL does not support the hiding of objects
between schemas. Basically, an object defined anywhere in the SCL is
visible everywhere else. What is supported is renamings of objects
between schemas. Say schema B uses entity X from schema A and renames
it to Y (i.e., "USE from A (X as Y);"). If a Part 21 file is read in
or written out using the SCL or the Data Probe, if the "current"
schema is defined to be B, the renamings defined by B's U/R statements
will be used. The "current" schema is set according to the first
schema listed in the FILE_SCHEMA section of the Part 21 file's header
section. (It is assumed that I/O is being done with the SCL's
STEPfile object.) If no current schema is defined, all possible
entity and type names are recognized in file reading, and the original
names only are used in writing.
As mentioned above, the SCL does not support the hiding of objects of
say, schema A, which are not U/R'ed by schema B. Thus, it's possible
to use the SCL or Data Probe to read or write a Part 21 file in which
A is the current schema and which contains instances of entities which
are not U/R'ed by A. This will not be flagged as an error.
The U/R clause is more poorly supported by the Data Probe. When the
Probe displays instances of entities, only their original names are
displayed. (This also applies when an entity has a select attribute
and the current choice of the select is being displayed by name. For
example, if a select is set to HEIGHT(35), the original name of
`HEIGHT' is displayed even if we're in schema B which renames HEIGHT
to LENGTH.) When a user is using a <<step entity editor window>> to
create an instance of an entity, all possible names for a type are
recognized. This includes the original object name plus all names
given to it by other U/R'ing schemas, regardless of the current
schema.
Another shortcoming with the U/R support is related to the fact that
the SCL does not allow objects of the same name in different schemas.
For this reason, U/R support is also limited to cases where the new
name is unique within the entire EXPRESS file.
Lastly, the U/R support is unable to deal with aggregate types of
two or more dimensions. Say we were attempting to instantiate a 2D
aggregate of selects. Type names will appear in the inner select
instantiations, and they should be set according to the current
schema. However, since the SCL currently does not fully support
higher-dimension aggregates (it uses the SCLundefined class and
considers the entire instantiation a string), it's impossible to
verify the values within the aggregate instance.
----------------------
COMPLEX ENTITY SUPPORT
----------------------
By complex entity, I mean ones which require external mapping (see Part 21,
section 11.2.5).
New Features
------------
(I really think the structures and functions I used to support this
are a recursive work of art. Too bad it's all invisible to the user.)
1. The primary enhancement now included is the checking of the
legality of complex entities. If a user attempts to initialize a
complex entity (class STEPcomplex), the SCL will determine, based on
the supertype and subtype information of the EXPRESS, if the entity
represents a legal combination of entities. If not, an error message
will be issued, and a complex entity will not be created. Formerly,
the SCL would only check if the entity names themselves were valid and
not worry about the combination.
2. Non-independent entities cannot be instantiated. These are
entities which cannot be created without external mapping. Say we
have,
ENTITY A SUPERTYPE OF (B AND C);
The SCL would not accept an instantiation statement such as,
#11=C(xx,yy,...);
C requires external mapping since it can only exist together with B,
in a statement such as,
#11=(A(...)B(...)C(...));
If a user attempts to create a C with internal mapping using the
STEPfile object (the class which handles all reading and writing of
Part 21 files within the SCL), an entity will not be created and an
error message will be issued. The SCL behaves similarly if a user
attempts to create an instance of an abstract supertype.
The above behavior is also reflected in the Data Probe. All entities
which are abstract supertypes are marked with an `*' (as in SCL vn.
2.1). Entities which cannot be instatiated without external mapping
are marked with a `%'. Neither can be created using the Data Probe.
(The Probe does not have the capability of creating complex entities,
see below, next section.)
(Note: A user can instantiate an entity such as C from the STEPentity
level, bypassing STEPfile. STEPentity will allow the initialization
but will place a warning in its errorDesc field.)
3. fedex_plus may be compiled with the flag COMPLEX_INFO. If this
flag is turned on, fedex_plus prints out (to `cout') a large amount of
detail on the complex entities it finds and their overall structure.
This is useful to see how fedex interpreted the complex information of
an EXPRESS file, and to get a simple graphical view of the supertype-
subtype hierarchy of the file.
fedex_plus's makefile contains the commented-out line,
#USER_DEFS = -DCOMPLEX_INFO
If this line is uncommented, a fedex_plus executable will be built
which prints such information.
Limitations
-----------
1. As in multi-schema support (above), complex entity (CE) support is
not completely reflected in the Data Probe. This may be seen in a
number of instances (you can skip this if you don't intend to use the
Probe):
(a) It's impossible to create an instance of a CE using the Data
Probe. (See point #2 under "Complex Entity Support").
(b) The Data Probe is able to correctly read a CE from a Part 21 file,
and place a copy of it in the Entity Instance List Window. It also
allows the user to edit the values of the entity's attributes by
selecting the entity (from the Ent Instance List Win) and creating a
STEP Entity Editor Window. The Data Probe, however, does not accu-
rately display the type information of the CE (in the Type Information
Window). What it does do is takes the name of the 1st entity in the
list (CE entity names are displayed alphabetically) and shows the type
info for that entity.
2. The SCL does not read partial complex instances. Generally, if a
single entity-member of a complex entity has an error, the entire rest
of the complex entity will be skipped.
3. If entity members of a complex entity have been renamed (through
the EXPRESS USE/REF clause - see previous section), they are read and
written properly. However, the SCL may not write the members of the
CE in alphabetical order (as required by Part 21, sect 11.2.5.3). The
individual entities are sorted according to their original names. If
the renaming of an individual entity places it out of order, the nodes
will be printed out of order.
4. "Diamond inheritance" is not handled automatically and must be
fixed by hand in the code generated by fedex_plus. (See
whatsnew.2-1.txt, section "Multiple Inheritance".)
5. Selects between aggregates: A select containing two aggregate
choices of the same type (e.g., ARRAY and ARRAY, as opposed to ARRAY
and SET) will cause fedex_plus to generate code which cannot be
compiled.
6. Problem with sparcworks compiler version 4.0(?) - operator int() =
op enum(). This happens in the following case... Both functions,
however, are required by Part 23. We fixed this by removing enough
functions for it to build. We were not sure if this error is the fault
of the sparcworks compiler or is a problem with the standard.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!DISCLAIMERS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Names of companies and products are provided in order to adequately
specify procedures and equipment used. In no case does such
identification imply recommendation or endorsement by the National
Institute of Standards and Technology, nor does it imply that the
products are necessarily the best available for the purpose.
NO WARRANTY
===========
NIST PROVIDES ABSOLUTELY NO WARRANTY. THE NIST STEP TOOLKIT
IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS
WITH YOU. SHOULD ANY PORTION OF THE NIST STEP TOOLKIT PROVE DEFECTIVE,
YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.
IN NO EVENT WILL NIST BE LIABLE FOR DAMAGES, INCLUDING ANY LOST
PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE, OR LOSSES
SUSTAINED BY THIRD PARTIES, OR A FAILURE OF THE PROGRAM TO OPERATE
WITH PROGRAMS NOT DISTRIBUTED BY NIST) THE PROGRAMS, EVEN IF YOU HAVE
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY
ANY OTHER PARTY.

86
whatsnew.3-2.txt
View file

@ -1,86 +0,0 @@
mkProbe now prints a usage message showing allowable command line
arguments when it is run without arguments.
Extended the EXPRESS Pretty Printer:
- added command line options -a and -A to the exppp executable to
specify that the output should be alphabetized. Without the -a option
the order of the TYPEs and entities in the original EXPRESS is
preserved when pretty printing an EXPRESS file.
- Fixed a bug in the exppp toolkit where it would crash when handling
PROCEDUREs in EXPRESS.
- Extended the NIST Pretty Printer Toolkit to provide string and
buffer representations for EXPRESS USE and REFERENCE statements, and
for providing access to the EXPRESS SUPERTYPE statements.
Extended the STEP Class Library Toolkit capabilities including:
- adding additional dictionary constructs for representing EXPRESS:
SUPERTYPE statements, WHERE rules within entities, USE FROM clauses,
REFERENCE FROM clauses, global rules, PROCEDUREs, and
FUNCTIONS. Information about these objects is available but validation
based on it is not performed.
- enhanced fedex_plus C++ code generator to generate the necessary
dictionary objects for the above EXPRESS constructs for a particular
schema. Also enhanced schema dictionary code generation to add
information necessary to generate an EXPRESS schema (i.e. which
entities, types, global rules, USE and REFERENCE statements, etc are
associated with which EXPRESS schema dictionary object).
- added capability to generate EXPRESS from the above dictionary
constructs (e.g. USE, REFERENCE, global rules, functions, procedures,
etc.) and the existing dictionary constructs for EXPRESS schemas,
types, entities, and attributes.
- Fixed a bug in the casting functions for the classes handling
instances of SELECT TYPEs in EXPRESS.
e.g.
SdaiMeasure_value::operator SCLP23(Real)()
{
// was missing stmts such as these...
if( CurrentUnderlyingType () == config_control_designt_area_measure )
return _real;
if( CurrentUnderlyingType () == config_control_designt_context_dependent_measure )
return _real;
}
- Fixed an aggregate element TypeDescriptor (TD) pointer problem in
the dictionary. The TD pointer in the aggregate dictionary entry is
supposed to point at the TD representing the element type for the
aggregate. It pointed at the underlying or base type's TD (e.g. the TD
for STRING) instead of for the type which was specified in the EXPRESS.
For example where it should have pointed at a TD for a TYPE label -
where label is defined as TYPE label = STRING; END_TYPE - it pointed
at the TD for STRING. The TD for the aggregate element now points at
the TD for label.
- Fixed the casting operator for the class representing EXPRESS
enumeration types. It was returning the last element of the enum type
as the the default when the enum was unset. This choice predated enums
having an unset enum value. It now returns <enum_name>_unset as the
default when the enum is unset.
- cleaned up a bit of leaked memory. The memory leaked was mostly
handles to static memory.
- sdaiString not reading a value '' properly.
- sdaiString copy constructor mixing up undefined and unset values.
- dictionary objects handling and writing WHERE rule and UNIQUE rule
comments in EXPRESS. Added a data member
SCLstring _comment; // Comment contained in the EXPRESS.
to classes Where_rule and Uniqueness_rule. Also they have functions:
SCLstring comment_() const { return _comment; }
void comment_(const char* c) { _comment = c; }
to manipulate them. When writing EXPRESS for entities and types the
keywords WHERE and UNIQUE are only written if there are actual
rules. If there are only comments the keywords are written as a
comment.