1
0
mirror of https://git.dev.opencascade.org/repos/occt.git synced 2025-08-14 13:30:48 +03:00

Compare commits

..

107 Commits

Author SHA1 Message Date
abv
b2c55ae578 Fix of compiler warnings on OCCT 7.0.0.beta (CLang and VC++ 14) 2015-12-27 15:42:56 +03:00
abv
fd7245ef38 0027041: CMake - CLang 3.6.2 fails to link DRAWEXE on Ubuntu 15.10
"stdc++" is added to CSF_ThreadLibs in CMake script to make DRAWEXE built well.

In addition, TKVCAF added in CMake script for OCAF MFC sample, and Yacc and Lex files added in src/StepFile/FILES to make it consistent with actual contents of the package.
2015-12-26 20:41:39 +03:00
ibs
d573adcf38 INSTALL_DIR is synced with CMAKE_INSTALL_PREFIX . Change of any of these vars resets the structure of the install folder 2015-12-25 10:57:44 +03:00
ibs
096ef695e1 0026916: Configuration, CMake - configure variables to customize installation path separately for executables, libraries and resources
change the structure of binaries for unix
OCCT_RESOURCE_PATH env variable is used
2015-12-25 10:29:12 +03:00
bugmaster
3554ea68da Final updates before release
- Update of mfc samples
- Adjustment of test cases
- Update of CSharp sample (lost button added)
- Corrected paths to data files in 07_Triangulation mfc sample
- Update of overview (Requirements section)
- Update of upgrade guide (changes in modeling algorithms)
2015-12-25 10:29:11 +03:00
myn
7ed7467da3 0026961: Recover possibility to read files in old persistence format -- preparation
Added basic support for possibility to read filed in old persistent format.
Toolkits TKStd, TKStdL, TKShape added to provide necessary tools (to be done).
Obsolete interfaces are removed from classes in PCDM and Storage.
2015-12-25 10:28:46 +03:00
apv
ede9746c21 0026354: Invalid result of General Fuse on wire and face
Test case for issue #26354
2015-12-25 10:21:33 +03:00
apv
a2b5448a0f 0026580: BRepProj_Projection does not provide any results
Test cases for issue #26580
2015-12-25 10:21:31 +03:00
apv
17abefd113 0026535: Boolean Cut does not work on shell and solids
Test case for issue #26535
2015-12-25 10:21:30 +03:00
nbv
9a7b15dc60 0027029: Possible regression in test de iges_1 L6 because of fix for issue 26837
In BRepLib::SameRange, allow exceeding curve range for periodic curves.

Test cases returned to the state before fix for issue #26837.
2015-12-24 17:30:46 +03:00
mkv
86e810711f 0026837: SameParameter algorithm throws an exception
Correction of test cases for issue CR26837
2015-12-23 20:45:41 +03:00
bugmaster
a1613f0a65 Incrementing OCCT version up to 7.0.0 beta 2015-12-23 13:40:41 +03:00
abv
ad121848e3 0027026: Modeling -- Improve AppCont_LeastSquare::AppCont_LeastSquare::FixSingleBorderPoint()
Update of test-cases according to the new behavior
2015-12-23 12:22:16 +03:00
vpa
5396886c90 0026960: Visualization, TKOpenGl - update transformation of dynamically highlighted presentation
- added method UpdateHighlightTrsf for immediate update of highlight presentation's transformation;
- interfaces for immediate transformation update of corresponding presentations were added to entity owner classes;
- test case for issue #26960
2015-12-23 11:36:44 +03:00
msv
3510db6201 0026619: Tolerances of operands are modified using bop
0026796: The result of General Fuse operation is self-intersecting shape

The fix forces creation of new sub-shapes (vertex, edge) when the tolerance of some sub-shape of an argument is to be increased.

This new behavior is turned off by default. It can be turned on using two ways:
1) Setting 'locking' flag of the arguments.
2) Calling the method SetNonDestructive(Standard_True) of the API classes.

Various bug fixes in the algorithm:
- Compute correct tolerance values for intersections of type Line/Line, Line/Plane, Plane/Plane.
- In case of Line/Plane intersection check if line's vertices lie on the plane.
- Do not allow decreasing of the tolerance value of the Line/Line intersection vertex.
- In IntTools_EdgeEdge, call the method FindParameters with proper 3D tolerance of the curve.
- Force making copy of a degenerated edge if its vertex is touched but no 2D intersection with other curves is found.
- Remove pave blocks both ends of which became referring to the same vertex after vertices substitution.
- Avoid exception in IntTools_Context::IsVertexOnLine if Extrema is not done.
- Reduce tolerance of vertex/edge using actual distances to interfered shapes if it was increased due to line/line, line/plane, or plane/plane small intersection angle.
- Update tolerance of edges to reach all representations in a common block.
- In V-E intersections, check if a vertex hits beyond shrunk range, in such case create V-V interference.
- Do not put a section edge to the result if it becomes to be a micro edge after updating its vertex.
- Correctly make vertices same-domain during the work of MakeBlocks.
- Decrease shrunk range at least on a Precision::Confusion() in addition to vertex tolerance.
- Add Confusion to bounding boxes of new shapes in DS
- Add tolerance Precision::Confusion() to compare distances of touching cases to fix regressions.

TODO marks have been removed from (or modified in) the following test cases (Improvements):
boolean bsection M3 N2 R2
boolean gdml_private B6 C2 C6 G7 I6 F6 J1 J4 M7 N1 N8 N9 O3 O4 O6 O8 O9 P1 P2 P5 Q1 Q3 Q5 S9 T2 U4 U5 U9 ZB5 ZB6 ZC1 ZC5 ZD3 ZD6 ZD7 ZH2 ZH5 ZI2 ZI5 ZI7 ZI9 ZJ3 ZJ4 ZJ7 F8 I6 G1
boolean volumemaker A5 A6 B3 B4 B7 B9 D3 D4 D7 F1
boolean bopcut_2d D5
bugs modalg_5 bug25043
bugs modalg_2 bug472_1 bug472_2 bug472_3

Test cases updated because they are still bad but can be accepted as non-regression:
boolean volumemaker C4 A3 A7 E6
bugs modalg_1 bug10232
boolean bsection N2

Put new TODO in the scripts:
bugs modalg_5 bug25232_9
bugs modalg_6 bug26619
bugs modalg_1 buc60462_2
bugs modalg_4 bug772

For the following tests the result in fix became better, so take fix result as the reference:
bugs modalg_5 bug24628
bugs modalg_6 bug26954_3
boolean volumemaker A4 B5 B6 C3 C8 D2 D5 F2
bugs modalg_2 bug472_2
bugs modalg_1 buc60776_1

- Add the method SetNonDestructive to API classes of user level
2015-12-23 10:33:43 +03:00
kgv
6435b9c7fa 0027031: Samples - fix compilation issues in java/jniviewer sample
Add -std=c++11 compiler flag to Android.mk.
OcctJni_Viewer - drop removed arguments within V3d_View::SetWindow() usage.
OcctJni_Window - add missing NativeFBConfig() method declared in the interface.
2015-12-22 18:12:36 +03:00
ifv
54f91e0332 0026837: SameParameter algorithm throws an exception
Test case for issue CR26837
2015-12-22 18:04:39 +03:00
duv
d2dfbc4d7d 0026433: AIS_Dimension may attempt to modify the state of default Drawer shading aspect
- Added checks to allow modification of only own aspects in AIS_Dimension::DrawText()
2015-12-22 16:10:05 +03:00
abv
dcc0a33ebd 0024514: Unclear guidelines to report issues in Mantis
Contribution workflow document is revised and extended to eliminate inconsistencies and describe the process in more details:

- Meaning of issue fields in Mantis (Category, Severity, Profile, Project and Target Version, etc.) is described in more details
- Additional rules are defined and examples given for defining Summary and Description, and writing commit messages
- Requirements for testing, creation of test case, update of user documentation, etc. when resolving an issue, are described
- Additional elements of the workflow (patch sumbission, rebasing branches, use of feedback status, issue relationships) are described

Some refinement in other guides; OCC logo updated for better quality.
2015-12-22 15:24:15 +03:00
abv
d1c596cfe1 0027023: Documentation -- cross-references are hardly noticeable in PDF
Doxygen option PDF_HYPERLINKS is set to NO to enforce generation of cross-references as explicit page numbers in PDF manuals
2015-12-22 15:24:11 +03:00
ysn
a3305c6e4e 0027020: Documentation -- proof-read upgrade guide
Developer guide update.md thoroughly checked and formatted.
2015-12-22 15:24:07 +03:00
ysn
f9e256b388 0026425: Update of OCCT contribution workflow
Requirements to the release documentation described in more details.
Added some suggestions concerning the workflow.
Workflow rewritten according to the remarks.
2015-12-22 15:24:03 +03:00
ysn
67d7f07f51 0026992: Use Doxygen tag @ref for cross-references in documentation
href have been replaced by @ref tags except for the links to web-pages and other documents where @ref tags do not work either.
2015-12-22 15:23:59 +03:00
ysn
27245ff9c0 0026964: Merge OCAF white-papers into OCAF user's guide
The text of white papers has been rearranged as follows:

OCAF white paper:
  Purpose of OCAF
  Overview of the architecture
  A look inside OCAF
- merged with the Introduction chapter

  Getting Started
  An example of OCAF usage
- added in Samples chapter

  The Data Framework
- merged with Data Framework Services chapter

  Persistent Data Storage
- added as a separate chapter

OCAF function mechanism white paper:
- added as a separate Example of Function Mechanism Usage chapter

Distribution of data through OCAF tree white paper:
- added as "The choice between standard and custom attributes" paragraph in Standard Attributes chapter.
2015-12-22 15:23:54 +03:00
akz
75c15b4392 0027000: Invalid result of ShapeUpgrade_UnifySameDomain
Add two test scripts to bugs/heal grid with involved in bug shapes
2015-12-22 14:59:37 +03:00
ibs
8f1f5a45cb 0027025: Configuration, CMake - do not get properties from non-VTK targets 2015-12-22 14:57:36 +03:00
ibs
109aa56ebe 0027022: Configuration, CMake - rename ungrouped variables to include them to the existing groups
APPLY_OCCT_PATCH_DIR renamed with BUILD_PATCH
OCCT_ALGO_EXTENDED_OUTPUT renamed with BUILD_WITH_DEBUG
REBUILD_PLATFORM_DEPENDENT_CODE renamed with BUILD_YACCLEX

3RDPARTY_DOXYGEN_DOT_EXECUTABLE renamed with 3RDPARTY_DOT_EXECUTABLE
2015-12-22 14:57:19 +03:00
ibs
a687470889 0026993: Configuration, CMake - use the abstraction level of VTK instead CSF_VTK for their libraries
CSF_VTK removed from CMake meta-projects (this variable is left in EXTERNLIB because it is used by genproj.tcl)
USE_VTK shown if toolkits using VTK involved in the solution
VTK_DIR removed from the advanced variables

Warning messages 'Warning. .../a.hxx~ is not involved into .../FILES' renamed with 'Warning: File .../a.hxx~ is not listed in .../FILES'
2015-12-22 14:57:15 +03:00
ibs
dfadf64138 0026878: CMake - encode properly version of OCCT in Windows binaries
.rc file has been added to each toolkit project for msvc
2015-12-22 14:47:10 +03:00
ifv
f85e7ddb9f 0027010: Wrong classification of the point relatively the solid
Algorithm of curve-face intersection was improved in order to take in account edge tolerance zones for more precise classification of state of intersection point.

Test case for issue CR27010
2015-12-22 14:36:51 +03:00
abv
59e4f50bf1 0026762: Static parameter "read.scale.unit" is not used
Parameter "read.scale.unit" is removed from sources and docs
2015-12-22 14:25:47 +03:00
aba
b12e1c7ba2 0025338: MFC standard samples: 3D selection rectangle blinking
- Added new interactive object AIS_RubberBand to draw rubber rectangle or polygon
- Added using of AIS_RubberBand in DRAW view for rectangular selection
- Added using of AIS_RubberBand in MFC samples for rectangular selection
2015-12-22 14:18:23 +03:00
abv
d9e9090564 0027016: Restore global type descriptors for old compilers
Global type descriptors are restored for VC++ 10 - 12 and GCC before 4.3.

Checks of compiler support of C++ features are corrected for GCC, ICC, and CLang in Standard_Handle.hxx
2015-12-22 14:15:01 +03:00
gka
727b5ad9fb 0026947: Data exchange can not be compiled without visualization anyomre
Dependence between STEP translator and visualization occurred due to addition class STEPConstruct_GDTProperty using enumeration from package XCAFDimTolObject.
In order to avoid this dependence class STEPConstruct_GDTProperty was moved in package STEPCAFControl and was renamed to STEPCAFControl_GDTProperty.
2015-12-22 14:12:07 +03:00
abv
59336f5c9d 0026951: Incorrect conversion of miles into millimeters during export to STEP
Coefficient for conversion of miles to mm is corrected in UnitsMethods::GetLengthFactorValue() to be 1609344.

In UnitsAPI/Units.dat, value of inch is corrected to be exactly 25.4 mm (it was 25.40001969); definition of nautical mile corrected to be exactly 1852 m.
Test bugs fclasses bug26951 is added to check definition of mm and miles.

DRAW command "unit" is corrected to put its output to Tcl instead of cout.
2015-12-22 14:08:52 +03:00
bugmaster
2f77210497 Adding checks in test cases 2015-12-20 14:49:14 +03:00
bugmaster
6ca259e871 Correction of test case 2015-12-18 11:31:05 +03:00
abv
d677b21418 Eliminate compiler warnings on VC++ 14 and CLang.
Remove unused stuff from OSD_WNT.cxx.
2015-12-18 10:35:16 +03:00
isk
20aeeb7be3 0026908: Visualization, TKOpenGl - eliminate -Wunused-parameter compiler warnings for Android target
Support TBO on OpenGL ES 3.2+
2015-12-17 18:59:36 +03:00
vpa
e9312c0fc2 0026973: Visualization - selection of entities hidden by clipping planes is broken
- misprint in distance calculation in SelectMgr_RectangularFrustum::IsClipped is corrected;
- selecting volume manager in clipping check in SelectMgr_ViewerSelector::checkOverlap was replaced ;
- added view-defined clipping planes check to SelectMgr_RectangularFrustum;
- test case for issue #26973.
2015-12-17 18:07:57 +03:00
ibs
4ff92abe44 0026229: Add the possibility in OCAF to open/save a document from/to a stream object
TDocStd_Application class extended to open/save a document of XmlOcaf and BinOcaf format
from/to standard SEEKABLE stream object which should support SEEK functionality.

Open and SaveAs DRAW commands got new additional argument "-stream" to turn on using of stream functionality.

The main changes for BinOcaf format applied in:
FSD_BinaryFile class (static method using standard stream added)
BinLDrivers_DocumentRetrievalDriver and BinLDrivers_DocumentStorageDriver classes use standard stream object as an argument

The main changes for XmlOcaf format applied in:
LDOMParser and LDOM_XmlWriter classes  use standard stream object as an argument

Unused class FSD_Archive and its siblings removed from MFC samples.
2015-12-17 18:03:34 +03:00
nbv
77dbd1f155 0026576: Wrong result obtained by intersection algorithm.
1. Algorithm of Restriction line decomposition has been created.
2. Algorithm of check of coincidences between Walking and Restriction line has been improved in new function IsCoincide(...) (which replaces IsIn2DBox(...)).
3. Some useful methods have been added in IntPatch_PointLine (and inherited) classes.

Test cases for this issue have been created.
2015-12-17 18:01:56 +03:00
gka
4f99f761b1 0024595: STEP import missing surfaces
Modification to create natural bounds for face based on the spherical and Bspline surface and having only one bound represented by Vertex loop was made.
 According to the specification of ISO-10303 part 42:
    "If the face has only one bound and this is of type vertex_loop, then the interior of the face is the domain of the face_surface.face_geometry. In such a case the underlying surface shall be closed (e.g. a spherical_surface.)"
    - natural bounds are applied only in case if VertexLoop is only the one
      defined face bound.

Update of test-cases according to the new behavior

Test-case for issue #24595
2015-12-17 17:55:47 +03:00
ski
4d6554d142 0026888: Crash in Java ImportExport sample on shape deleting
Corrected behaviour of 3d viewer after shape deleting in qt samples.
Corrected behaviour of toolbar buttons after shape deleting in csharp samples.
2015-12-17 17:47:03 +03:00
ski
f4264b5adb 0016472: Improve environment scripts for samples
Output directory for binaries of CSharp samples was corrected.
Common run.bat was created for CSharp samples.
Behaviour of run.bat file from mfc samples was extended.

Recovered separate run_*.bat files for each sample in CSharp sample.
2015-12-17 17:38:42 +03:00
ysn
9d99d3c16d 0026212: There are some problems with location of text and images on pages
Fixes to improve layout of  images and formula in generated PDF documentation.
2015-12-17 17:31:54 +03:00
vpa
3667907665 0026959: Visualization - cannot select edge of the shape
- polygonal representation of the edge is used for sensitive entity computation regardless of requested deflection;
- test case for issue #26959

Adjusting test case
2015-12-17 17:17:44 +03:00
nbv
47e3009da9 0026841: Boolean operation "bsection" produce invalid result on the attached cases
1. Intersection curve was not bounded by faces domain. It was the reason of big edge tolerance. This problem has been fixed.
2. Interface bopcurves DRAW-command has been changed in order to make possible to reproduce intersection problem.

Creation of test case for this issue.
2015-12-17 17:12:04 +03:00
gka
c9e1d810ab 0026708: Fix shape did not fix attached shape. Seam edge was not added to the attached periodic face.
Added taking into account crossing seam edge during collection of the wires in the ShapeFix_ComposeShell.cxx
Test script for bug 0026708.
2015-12-17 16:59:46 +03:00
kgv
905db76982 0026995: Visualization, TKXCAF - do not reset custom material within XCAFPrs_AISObject::Compute()
Assign default material in class constructor instead.
2015-12-17 16:49:28 +03:00
vro
1ff072271f 0023465: Weird InsertBefore, InsertAfter and Remove methods in TDataStd lists 2015-12-17 16:47:40 +03:00
abv
c785481848 0026988: Fresh compiler warnings (VC++ 14, GCC 5.2.1, CLang 3.6.2)
Compiler warnings eliminated:

- VC++: potential use of uninitialized variable
- GCC: potential use of uninitialized variable [-Wmaybe-uninitialized], redundant const on return value [-Wignored-qualifiers]
- CLang: missing override specifier on overloaded virtual function [-Winconsistent-missing-override], function call within typeid() [-Wpotentially-evaluated-expression]
2015-12-17 16:41:34 +03:00
abv
795be040eb 0026551: Optimization of initialization of OCCT RTTI
Global instances of type descriptors are eliminated as unnecessary
2015-12-17 16:41:29 +03:00
Roman Lygin
a0218ba1c5 0026913: Vulnerable mechanism in Standard_Type leads to assert 2015-12-17 16:41:24 +03:00
vpa
325e442bce 0026945: Visualization - selection does not work after closing one of local contexts in stack
- added method to restore selection of local context;
- activated standard modes are added to local status now;
- test case for issue #26945
2015-12-17 16:39:11 +03:00
isk
16420da1d4 0026984: Draw Harness, ViewerTest - preserve local transformation of presentation within vtexture command 2015-12-17 16:35:58 +03:00
msv
a2ff7810d8 0026967: BRepFill_OffsetWire should not copy plane if Alt == 0.0
In the class BRepFill_OffsetWire the base plane is not copied anymore if altitude parameter is equal to zero.
2015-12-17 16:34:11 +03:00
mkv
64b470617f 0023666: Wrong section curve between attached faces
Test case for issue CR23666

Small correction of test case in accordance with changes of issue 25945
2015-12-17 16:30:58 +03:00
mkv
5b70cbe8c1 0026523: Wrong result of section algorithm
Small correction of test case in accordance with changes of issue 25945
2015-12-17 16:15:03 +03:00
isk
74fb257d6c 0026892: Visualization, TKOpenGl - support 3D textures within OpenGl_Texture
Add a new arbTexFloat extension in OpenGl_Context.
Add a new prototype glTexImage in OpenGl_GlFunctions.
Push error message if glTexImage3D is unavailable.
2015-12-17 15:58:58 +03:00
isk
ad2a55b2f3 0026975: Visualization, TKOpenGl - handle triangle strips correctly within Ray-Tracing core 2015-12-17 15:52:06 +03:00
mkv
702ef49f22 0025342: [Regression] BRepAlgoAPI_Section returns wrong number of edges
Test case for issue CR25342
2015-12-17 15:48:38 +03:00
mkv
3da62e0ec3 0026334: BRepOffsetAPI_MakePipeShell returns the wrong shape 2015-12-17 15:41:31 +03:00
mkv
e1312bce25 0026188: Incorrect PCurve creation
Test case for issue CR26188
2015-12-17 15:34:21 +03:00
mkv
6b13d5288e 0026327: Performance degradation from version 6.8.0 on Boolean operations
Test case for issue CR26327
2015-12-17 15:26:15 +03:00
nbv
c8f62d27b0 0026896: Wrong result of bsection algorithm
Creation test cases for this issue

Small correction of test cases
2015-12-17 15:18:02 +03:00
nbv
ed9ce6777f 0026848: Result of BO depends on arguments order
Correction test case for this issue

Test cases for CR26848
2015-12-17 15:04:11 +03:00
mkv
8d27a37d80 0026427: Draft angle algorithm produces wrong shape
Test case for issue CR26427
2015-12-17 14:52:19 +03:00
ski
2f9dedc5fe Modification of test cases in accordance with changes of issue 25945 2015-12-11 11:35:18 +03:00
msv
6e2cb64d8f 0026970: Update MSVC visualizers to support 7.0 handles and something more
Changes:
- make shorter visualization of handles: change word 'count' to 'cnt'
- add visualization of hex value of entity in handles
- add visualization of classes:
opencascade::handle<*>
NCollection_Sequence<*>
TColStd_Array1OfInteger
TColStd_Array1OfReal
TColStd_Array2OfInteger
TColStd_ListOfInteger
TColStd_ListOfReal
BRep_ListOfCurveRepresentation
TopoDS_Shape
TopoDS_TShape
BOPDS_Pave
BOPDS_PaveBlock
2015-12-10 17:28:09 +03:00
ysn
d376db7a1e 0026926: Small mistake in the exceptions part of Foundation Classes User's Guide
A minor clarification
2015-12-10 17:24:34 +03:00
ski
58cf74e0c0 0025945: Make stable checking of shape global properties in tests
- Added function checkprops, set default tolerance parameter to 1.0e-4
- Using "area" instead of "square".
- Options "-equal\notequal" isn't used together with "-s" in blend and offset test cases.
- Correct regressions/differences/improvements and CPU problem (set props tolerance to 0.1)
- Corrected test cases to use checkprops proc.
- Correct image difference
- Updated TODOs in test cases.
- Updated test cases to get correct images of result shape
2015-12-10 16:56:03 +03:00
nbv
5fb5b5c432 0024417: BRepAlgoAPI_Section fails on attached shapes
Creation test case for this issue
2015-12-10 16:46:04 +03:00
emv
acb81c8314 0026955: Invalid result of General Fuse operation
Running Solid Classifier algorithm with correct tolerance for point.
2015-12-10 15:59:59 +03:00
szy
f47afe531d 0026290: It is neccessary to separate visualization part from TKCAF
- Package TPrsStd is moved into new toolkit TKVCAF. This is the only toolkit in OCAF that depends on visualization libraries.

- All persistent data stored in TPrsStd_AISPresentation attribute are moved to new attribute TDataXtd_Presentation, which is maintained automatically on the same label as TPrsStd_AISPresentation.
All parameters used by TPrsStd_AISPresentation are stored in corresponding TDataXtd_Presentation attribute.

- TPrsStd_AISPresentation is not stored in file any more; when OCAF document is loaded from a file, these attributes are created at all labels where TDataXtd_Presentation attribute is located, by TPrsStd_AISViewer::New().

- File src/StdResources/MigrationSheet.txt necessary for reading files written by previous versions of OCCT (lost in one of previous integrations) is restored and updated as necessary to handle this change (defines replacement of TPrsStd_AISPresentation by TDataXtd_Presentation). Environment variable CSF_MIGRATION_TYPES should be defined, pointing to this file.

- Packages BinMPrsStd and XmlMPrsStd are removed; their drivers are moved into BinMDataXtd and XmlMDataXtd respectively.

- Version numbers of BinOCAF and XmlOCAF formats are increased, new files cannot be read by previous versions of OCCT

- New tests added

- Adding new TKVCAF toolkit in sample projects

- Restore IsDisplayed(false) in TPrsStd_AISPresentation::Erase()
2015-12-10 15:55:00 +03:00
emv
d0fc16452d 0026971: Test cases for Set-45 2015-12-10 15:48:39 +03:00
emv
593f18f8ec 0026954: Test cases for Set-44
The cases for the customer's set Set-44.
2015-12-10 15:48:37 +03:00
emv
f1eca450db 0026952: Test cases for Set-41
The cases for the customer's set Set-41.
2015-12-10 15:48:36 +03:00
emv
a84c3447ad 0026953: Test cases for Set-43
The cases for the customer's set Set-43.
2015-12-10 15:48:35 +03:00
Istvan Csanady
3b25c0e867 0026949: Geom(2d)Adaptor_Curve/Surface should not do down casts in evaluation
Prevent downcasting in curve evaluation in GeomAdaptor classes
2015-12-10 15:48:33 +03:00
abv
92efcf78a6 0026936: Drawbacks of inlining in new type system in OCCT 7.0 -- automatic
Automatic restore of IMPLEMENT_STANDARD_RTTIEXT macro (upgrade -rtti)
2015-12-04 14:15:06 +03:00
abv
f5f4ebd07b 0026936: Drawbacks of inlining in new type system in OCCT 7.0 -- manual
Restored possibility to have out-of-line implementation of DynamicCast() and STANDART_TYPE():
- Macro STANDARD_TYPE() now resolves to function get_type_descriptor() of the class
- Macro DEFINE_STANDARD_RTTI is replaced by two variants:
  - DEFINE_STANDARD_RTTI_INLINE works as before, defining DynamicCast() and get_type_descriptor() as inline functions
  - DEFINE_STANDARD_RTTIEXT declares DynamicCast() and get_type_descriptor() as exported
- Macro IMPLEMENT_STANDARD_RTTIEXT provides definition of DynamicCast() and get_type_descriptor() for a class

Upgrade script amended to replace DEFINE_STANDARD_RTTI by pair of DEFINE_STANDARD_RTTIEXT / IMPLEMENT_STANDARD_RTTIEXT if source file with the same name as header is found in the same folder, and by DEFINE_STANDARD_RTTI_INLINE if either source is not found or class is defined in the source (i.e. not in header)

Upgrade tool improved to recognize include statements with path prefix, like #include <occt/gp_Pnt.hxx>
Code corrected to eliminate warnings reported by upgrade tool.
Template of CXX file for testing upgrade tool added.

Documentation of upgrade procedure updated.
2015-12-04 13:57:58 +03:00
ika
6595eee796 0026859: Export of GDT from XCAF to STEP
Export/Import:
Add export of dimensions, geometric tolerances and datums, according to AP242.
Add missing STEP entities.
Corrections.

XCAF:
Add new attributes to Datum object: DatumTargetNumber.
Supplement enum XCAFDimTolObjects_GeomToleranceZoneModif.
Corrections.

Test cases:
gdt export A1
gdt export A2
gdt export A3
gdt export A4
gdt export A5
2015-12-04 13:16:58 +03:00
nbv
4e14c88f77 0026431: Can't cut a sphere from a cylinder
This branch contains fixes for 26675 and 26431 bugs.

1. Normalization has been eliminated.
2. Interfaces of AppDef_Compute::Parametrization(...) and BRepAlgo_BooleanOperations::SetApproxParameters() methods have been changed.
3. Overloaded methods for ApproxInt_Approx::SetParameters(...), TopOpeBRepTool_GeomTool::GetTolerances(...) and TopOpeBRepTool_GeomTool::SetTolerances(...) have been removed (because some fields of these classes are not used more).
4. Comments for some methods have been changed in BRepApprox_TheMultiLineOfApprox.hxx and GeomInt_TheMultiLineOfWLApprox.hxx files.
5. Some fields have been deleted from ApproxInt_MultiLine class. Kept members have become constant.
6. Interface of ksection DRAW-command has been changed.
7. Now, 2dintersect DRAW-command prints information about found segments.
8. Some code fragments have been rewritten to make them easier.
9. Algorithm of splitting WLine, which goes through pole of sphere has been improved.
10. Improve approximation algorithm in order to it will compute correct 2D- and 3D-tangent at the end of bezier constraints (including case when curve goes through or finishes on singular points).
11. Interface of IntPatch_WLine::Dump(...) method has been corrected.
12. Some methods for working with Walking-line are made more universal (available for both GeomInt and IntTools packages).
13. Problem in BRepLib::SameParameter(...) method has been fixed (see corresponding comment).
14. Small correction in Draft package.
15. Any outputs in IntPatch_Intersection::Dump(...) method have become disabled because they are useless. If anybody need in this outputs he/she will correct this method himself/herself.

Adjusting some test cases according to their new behavior.
Creation of new test cases.

----------------------------------------------------------------------------------------------------------------------------

Some explanation of new behavior of some test cases:

 1. Regressions:

a) blend simple X4
The problem is described in the issue #0026740. According to this description,  the result on the current MASTER seems to be wrong indeed.

b) boolean bcommon_complex C7 and boolean bcut_complex Q1
These test case use same shapes with different Boolean operation (COMMON and CUT). They are already BAD (on the MASTER). Now, some sub-shapes have become not-shared, simply. In my opinion, we shall apply new behavior of these tests.

c) boolean bsection M3
The problem described in the issue #0026777 exists even on the current MASTER.

d) boolean bsection M9
The problem is described in the message http://tracker.dev.opencascade.org/view.php?id=26815#c47546. Here, we have really regression in the picture.

e) boolean bsection N2

The problem is described in issue #0026814.

f) boolean volumemaker G1

The problem is described in issue #26020.

g) bugs modalg_1 bug1255 (and bug1255_1)

The problem is described in issue #26815.

h) bugs modalg_2 bug5805_18, bugs modalg_2 bug5805_42, bugs modalg_2 bug5805_46

The problem is described in issue #25925.

i) bugs modalg_3 bug602

The problem is describes in issue #602.

j) bugs modalg_5 bug24915

The problem is described in the message http://tracker.dev.opencascade.org/view.php?id=25929#c48565. It is not fixed by this issue.

k) bugs modalg_5 bug25838

The main reason is described in issue #0026816.

----------------------------------------------------------------------------
2. Improvements:

a) boolean volumemaker F9
b) bugs modalg_1 bug10160_3
c) bugs modalg_2 bug22557
d) bugs modalg_5 bug25319_1 (_2)
e) draft angle G2
f) offset shape A1
g) offset with_intersect_80 N7
2015-12-04 13:15:04 +03:00
aml
f44aa19760 0025929: Make Approx_ComputeLine algorithm adaptive
Adaptive partition algorithm of WLine is implemented and used in ApproxInt_Approx.gxx file.
Refactoring of ApproxInt_Approx class.
Test cases are updated to the new behaviour.

Filtering algorithm improved.
2015-12-04 13:12:09 +03:00
abv
600f8c7f47 CSF_TBB added for toolkits that need to link to TBB 2015-12-04 13:03:51 +03:00
ski
0e617b05e7 0026902: Configuration, CMake - tests is not installed after definition INSTALL_OCCT_TEST_CASES option
Variables responsible for installation of tests and samples were renamed
2015-12-04 13:03:47 +03:00
mgn
586db386eb 0026922: Huge performance issue writing data to the output stream
Test case for issue CR26922

Correction of literal (char to string)
2015-12-04 13:03:41 +03:00
kgv
cc6852f3e9 0026940: Visualization, TKOpenGl - capping plane should be applied to connected structures
OpenGl_Structure::Render(), OpenGl_CappingAlgo::RenderCapping() - render
groups of instanced and this structure in the same manner
using ::renderGeometry() and ::renderClosedGeometry() instead of ::DrawGroups().
Skip capping algo for structures without groups of closed primitives.
2015-12-04 13:03:28 +03:00
azv
d660a72aca 0026838: Using GeomEvaluators for calculation of values of curves
1. Implemented evaluators for 2D and 3D offset curves
2. Removed obsolete namespace CSLib_Offset

Update of UDLIST (adding no-cdl-pack Geom2dEvaluator)

Update TKG2d/CMakeLists.txt after rebase

Correction compilation in debug mode
2015-11-27 11:49:40 +03:00
apl
badc9305ae 0026658: Unexpected selection in the context using a selection filter.
Method AIS_LocalContext::ClearOutdatedSelection() fixed. Now it chooses "mylastindex" value from list of filtered detected owners. The topmost detected owner will be highlighted if the current detected owner was cleared as outdated.

BUC26658 command to check the bug fix in DRAW.

append a test script to automatically check the bug in DRAW.

warnings correction.
2015-11-27 10:20:34 +03:00
apl
97f937cc55 0026792: Visualization, Graphic3d - Z-fit support for transform persistence is missing after removing Visual3d_View
Add missing code for z-fit support for zoom, rotate persistent object.
Fixed wrong statement that should enable frustum culling optimization for zoom, rotate persistent object.
Fixed BVH_LinearBuilder.lxx to correctly control number of items in leaf node for a case of items with equal bounding boxes.
Added non-regression test case for z-clipping of transform persistent objects.
2015-11-27 10:18:12 +03:00
azv
c8b5b3d89e 0023620: Follow up of 0022939 - make Bezier curve/surface evaluation thread-safe
1. Remove cache from Geom_BezierCurve, Geom2d_BezierCurve and Geom_BezierSurface
2. Add cache for Bezier curves into GeomAdaptor_Curve, Geom2dAdaptor_Curve and GeomAdaptor_Surface
3. Update comments in corresponding cache classes
4. Avoid frequent down-casting to B-splines in adaptors
2015-11-27 10:08:50 +03:00
azv
525ec87c53 0026914: [Regression 7.0alpha] Hang in surface approximation
Change a constructor of evaluator for offset surfaces

Test-case for issue #26914
2015-11-27 10:08:45 +03:00
ika
5371131494 0026451: Crash importing STeP file
Add check for NULL.
2015-11-27 10:08:40 +03:00
kgv
b128c89231 0026915: Visualization - return Handle from Graphic3d_CView::FBOCreate() instead of a pointer
OpenGl_View::FBO() - use copy Handle constructor for compatibility.
2015-11-27 10:08:35 +03:00
osa
6bd94e0de9 0026348: Visualization, TKOpenGl - eliminate invalid NULL checks for transformation matrix
Graphic3d_CStructure::Transformation - use Graphic3d_Mat4 instead of plain arrays.
Drop duplicating field OpenGl_Structure::myTransformation (copy of Graphic3d_CStructure::Transformation).
Drop unused property Graphic3d_CStructure::Composition and Graphic3d_Structure::Composition().
2015-11-27 10:08:30 +03:00
vro
f486f64d86 0026005: Problem with transient TFunction_Logbook 2015-11-27 10:08:24 +03:00
azv
8156ddddc7 0026897: BRepBuilderAPI_Copy does not copy polygons
1. Implemented copying for 3D polygons and polygons on surfaces
2. Added test case bugs/modalg_6/bug26897
2015-11-27 10:08:18 +03:00
isk
fbef84f9eb 0026891: Visualization, TKOpenGl - define more texture types within OpenGl_TextureFormatSelector 2015-11-27 10:08:13 +03:00
vpa
95081657f1 0026905: Visualization - cosmetic fixes in selection methods of AIS_InteractiveContext
- selection mode in AIS_InteractiveContext::AddOrRemoveSelected is corrected;
- AIS_InteractiveContext::IsSelected returns object's state instead of global status.
2015-11-27 10:08:08 +03:00
azv
6a2ee09493 0026871: [Regression in 6.9.0] Projecting a curve hangs inside Approx_FitAndDivide2d
Fix checking of B-spline parametrization speed

Test case for issue CR26871
2015-11-27 10:08:03 +03:00
nbv
ce48b00930 0026884: Cylinder/Cylinder intersection algorithm throws an exception
Check, if cylinder axes are parallel is made more carefully.
This check is brought to conformity with check if axes are parallel (see constructor AxeOperator::AxeOperator(...) in IntAna_QuadQuadGeo.cxx file)

Test case for issue CR26884
2015-11-26 12:05:36 +03:00
rkv
c16915c713 0026625: Possible wrong use of vtkSmartPointer<T> in IVtkVTK_ShapeData.cxx
Use vtkSmartPointer<XXX>::New() instead of XXX::New() when initializing fields of vtkSmartPointer<XXX> types.
2015-11-26 12:02:09 +03:00
aba
4d147bf2a7 0025549: Visualization - do not crash on attempt to display the Angle dimension between two parallel lines
- Handle cases of 0 and Pi angle depending on lines in edges and end points

Draw arcs in accordance with input normal for minimum angle, check correctness of input circle parameters
2015-11-26 11:59:30 +03:00
bugmaster
bd485d9691 Redirection of generation reference documentation from source files 2015-11-24 16:36:34 +03:00
bugmaster
31dfc19fcb Copy env.bat file from adm/templates 2015-11-24 16:11:22 +03:00
8338 changed files with 47460 additions and 30625 deletions

View File

@@ -6,8 +6,8 @@ set (CMAKE_CONFIGURATION_TYPES Release Debug RelWithDebInfo CACHE INTERNAL "" FO
# macro: include patched file if it exists
macro (OCCT_INCLUDE_CMAKE_FILE BEING_INCLUDED_FILE)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${BEING_INCLUDED_FILE}.cmake")
include (${APPLY_OCCT_PATCH_DIR}/${BEING_INCLUDED_FILE}.cmake)
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${BEING_INCLUDED_FILE}.cmake")
include (${BUILD_PATCH}/${BEING_INCLUDED_FILE}.cmake)
else()
include (${CMAKE_SOURCE_DIR}/${BEING_INCLUDED_FILE}.cmake)
endif()
@@ -31,10 +31,27 @@ endif()
# the name of the project
project (OCCT)
# include occt macros
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/occt_macros")
# Solution folder property
set_property (GLOBAL PROPERTY USE_FOLDERS ON)
set (INSTALL_OCCT_TEST_CASES OFF CACHE BOOL "${INSTALL_OCCT_TEST_CASES_DESCR}")
# get current OCCT version
OCC_VERSION (OCC_VERSION_MAJOR OCC_VERSION_MINOR OCC_VERSION_MAINTENANCE OCC_VERSION_DEVELOPMENT OCC_VERSION_STRING_EXT)
set_property (GLOBAL PROPERTY OCC_VERSION_MAJOR ${OCC_VERSION_MAJOR})
set_property (GLOBAL PROPERTY OCC_VERSION_MINOR ${OCC_VERSION_MINOR})
set_property (GLOBAL PROPERTY OCC_VERSION_MAINTENANCE ${OCC_VERSION_MAINTENANCE})
set (INSTALL_TEST_CASES OFF CACHE BOOL "${INSTALL_TEST_CASES_DESCR}")
# single-configuration generator
set (SINGLE_GENERATOR OFF)
if (CMAKE_BUILD_TYPE)
set (SINGLE_GENERATOR ON)
endif()
# a single-configuration generator like the Makefile generator defines CMAKE_BUILD_TYPE variable
# check this variable and set if it's required
if (DEFINED CMAKE_BUILD_TYPE AND NOT CMAKE_BUILD_TYPE) # single-configuration generator.
@@ -42,19 +59,127 @@ if (DEFINED CMAKE_BUILD_TYPE AND NOT CMAKE_BUILD_TYPE) # single-configuration ge
endif()
# enable extended messages of many OCCT algorithms
set (OCCT_ALGO_EXTENDED_OUTPUT OFF CACHE BOOL "${OCCT_ALGO_EXTENDED_OUTPUT_DESCR}")
if (OCCT_ALGO_EXTENDED_OUTPUT)
set (BUILD_WITH_DEBUG OFF CACHE BOOL "${BUILD_WITH_DEBUG_DESCR}")
if (BUILD_WITH_DEBUG)
add_definitions (-DOCCT_DEBUG)
endif()
# copy samples to install directory
set (INSTALL_OCCT_SAMPLES OFF CACHE BOOL "${INSTALL_OCCT_SAMPLES_DESCR}")
set (INSTALL_SAMPLES OFF CACHE BOOL "${INSTALL_SAMPLES_DESCR}")
# install dir of the built project
set (INSTALL_DIR "" CACHE PATH "${INSTALL_DIR_DESCR}" )
set (CMAKE_INSTALL_PREFIX "${INSTALL_DIR}" CACHE INTERNAL "" FORCE )
# install dir of the project
if (NOT DEFINED INSTALL_DIR)
set (INSTALL_DIR "${CMAKE_INSTALL_PREFIX}" CACHE PATH "${INSTALL_DIR_DESCR}")
endif()
set (APPLY_OCCT_PATCH_DIR "" CACHE PATH "${APPLY_OCCT_PATCH_DIR_DESCR}")
if (NOT DEFINED CMAKE_INSTALL_PREFIX_PREV)
set (CMAKE_INSTALL_PREFIX_PREV "${CMAKE_INSTALL_PREFIX}" CACHE INTERNAL "" FORCE)
elseif (NOT "${CMAKE_INSTALL_PREFIX_PREV}" STREQUAL "${CMAKE_INSTALL_PREFIX}")
# CMAKE_INSTALL_PREFIX has been changed at previous step
set (CMAKE_INSTALL_PREFIX_PREV "${CMAKE_INSTALL_PREFIX}" CACHE INTERNAL "" FORCE)
# INSTALL_DIR is required to be updated
set (INSTALL_DIR "${CMAKE_INSTALL_PREFIX}" CACHE PATH "${INSTALL_DIR_DESCR}" FORCE)
endif()
if (NOT DEFINED INSTALL_DIR_PREV)
set (INSTALL_DIR_PREV "${INSTALL_DIR}" CACHE INTERNAL "" FORCE)
elseif (NOT "${INSTALL_DIR_PREV}" STREQUAL "${INSTALL_DIR}")
# INSTALL_DIR has been changed at previous step
set (INSTALL_DIR_PREV "${INSTALL_DIR}" CACHE INTERNAL "" FORCE)
# sync CMAKE_INSTALL_PREFIX with INSTALL_DIR
set (CMAKE_INSTALL_PREFIX "${INSTALL_DIR}" CACHE INTERNAL "" FORCE)
# set CMAKE_INSTALL_PREFIX_PREV to avoid the reset of structure of the install folder
set (CMAKE_INSTALL_PREFIX_PREV "${INSTALL_DIR}" CACHE INTERNAL "" FORCE)
# The structure of install folder should be reset
OCCT_CHECK_AND_UNSET (INSTALL_BIN_DIR)
OCCT_CHECK_AND_UNSET (INSTALL_SCRIPT_DIR)
OCCT_CHECK_AND_UNSET (INSTALL_LIB_DIR)
OCCT_CHECK_AND_UNSET (INSTALL_INCLUDE_DIR)
OCCT_CHECK_AND_UNSET (INSTALL_OCCT_RESOURCE_DIR)
OCCT_CHECK_AND_UNSET (INSTALL_SHARE_DIR)
endif()
# hide CMAKE_INSTALL_PREFIX from a user
set (CMAKE_INSTALL_PREFIX "${INSTALL_DIR}" CACHE INTERNAL "" FORCE)
set (BIN_LETTER "")
if ("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
set (BIN_LETTER "d")
elseif ("${CMAKE_BUILD_TYPE}" STREQUAL "RelWithDebInfo")
set (BIN_LETTER "i")
endif()
# Get all used variables: OS_WITH_BIT, COMPILER
OCCT_MAKE_OS_WITH_BITNESS()
OCCT_MAKE_COMPILER_SHORT_NAME()
# do not define INSTALL_BIN_DIR for win.
# Leave library structure for win: <prefix>/win64/vc10/bin(d)
if (NOT DEFINED INSTALL_BIN_DIR)
if (UNIX)
set (INSTALL_BIN_DIR "${INSTALL_DIR}/bin" CACHE PATH "${INSTALL_BIN_DIR_DESCR}")
else()
if (SINGLE_GENERATOR)
set (INSTALL_BIN_DIR "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin${BIN_LETTER}" CACHE PATH "${INSTALL_BIN_DIR_DESCR}")
endif()
endif()
endif()
# define folder contaning all shell/batch scripts
if (NOT DEFINED INSTALL_SCRIPT_DIR)
if (UNIX)
set (INSTALL_SCRIPT_DIR "${INSTALL_BIN_DIR}/opencascade-${OCC_VERSION_STRING_EXT}" CACHE PATH "${INSTALL_SCRIPT_DIR_DESCR}")
else()
set (INSTALL_SCRIPT_DIR "${INSTALL_DIR}" CACHE PATH "${INSTALL_SCRIPT_DIR_DESCR}")
endif()
endif()
# place the libraries to <prefix>/lib folder for unix and leave old structure for windows
if (NOT DEFINED INSTALL_LIB_DIR)
if (UNIX)
set (INSTALL_LIB_DIR "${INSTALL_DIR}/lib" CACHE PATH "${INSTALL_LIB_DIR_DESCR}")
else()
if (SINGLE_GENERATOR)
set (INSTALL_LIB_DIR "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib${BIN_LETTER}" CACHE PATH "${INSTALL_LIB_DIR_DESCR}")
endif()
endif()
endif()
# OCCT headers: <prefix>/inc for windows,
# <prefix>/include/opencascade-7.0.0 for unix
if (NOT DEFINED INSTALL_INCLUDE_DIR)
if (UNIX)
set (INSTALL_INCLUDE_DIR "${INSTALL_DIR}/include/opencascade-${OCC_VERSION_STRING_EXT}" CACHE PATH "${INSTALL_INCLUDE_DIR_DESCR}")
else()
set (INSTALL_INCLUDE_DIR "${INSTALL_DIR}/inc" CACHE PATH "${INSTALL_INCLUDE_DIR_DESCR}")
endif()
endif()
# OCCT resources: <prefix>/src for windows,
# <prefix>/share/opencascade-7.0.0/resources for unix
if (NOT DEFINED INSTALL_OCCT_RESOURCE_DIR)
if (UNIX)
set (INSTALL_OCCT_RESOURCE_DIR "${INSTALL_DIR}/share/opencascade-${OCC_VERSION_STRING_EXT}/resoures" CACHE PATH "${INSTALL_OCCT_RESOURCE_DIR_DESCR}")
else()
set (INSTALL_OCCT_RESOURCE_DIR "${INSTALL_DIR}/src" CACHE PATH "${INSTALL_OCCT_RESOURCE_DIR_DESCR}")
endif()
endif()
# OCCT data
if (NOT DEFINED INSTALL_SHARE_DIR)
if (UNIX)
set (INSTALL_SHARE_DIR "${INSTALL_DIR}/share/opencascade-${OCC_VERSION_STRING_EXT}" CACHE PATH "${INSTALL_SHARE_DIR_DESCR}")
else()
set (INSTALL_SHARE_DIR "${INSTALL_DIR}" CACHE PATH "${INSTALL_SHARE_DIR_DESCR}")
endif()
endif()
# a directory recognized as a 'patch' for OCCT
set (BUILD_PATCH "" CACHE PATH "${BUILD_PATCH_DESCR}")
# the list of being built toolkits
set (BUILD_ADDITIONAL_TOOLKITS "" CACHE STRING "${BUILD_ADDITIONAL_TOOLKITS_DESCR}")
@@ -68,15 +193,11 @@ endif()
if (APPLE)
set (USE_GLX OFF CACHE BOOL "${USE_GLX_DESCR}")
endif()
if (WIN32)
set (USE_D3D OFF CACHE BOOL "${USE_D3D_DESCR}")
endif()
set (USE_VTK OFF CACHE BOOL "${USE_VTK_DESCR}")
# include occt macros
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/occt_macros")
# include the patched or original list of modules
# list <MODULENAME>_TOOLKITS is created foreach module and contains its toolkits
# list <OCCT_MODULES> will contain all modules
@@ -94,11 +215,6 @@ endif()
# Overview
set (BUILD_DOC_OcctOverview OFF CACHE BOOL "${BUILD_DOC_OcctOverview_DESCR}")
if (NOT USE_VTK)
list (REMOVE_ITEM Visualization_TOOLKITS TKIVtk)
list (REMOVE_ITEM Draw_TOOLKITS TKIVtkDraw)
endif()
if (NOT USE_D3D)
list (REMOVE_ITEM Visualization_TOOLKITS TKD3DHost)
endif()
@@ -121,7 +237,7 @@ endif()
# accumulate all used toolkits
list (REMOVE_DUPLICATES BUILD_TOOLKITS)
set (RAW_BUILD_TOOLKITS)
foreach(BUILD_TOOLKIT ${BUILD_TOOLKITS})
foreach (BUILD_TOOLKIT ${BUILD_TOOLKITS})
OCCT_TOOLKIT_FULL_DEP (${BUILD_TOOLKIT} TOOLKIT_FULL_DEPS)
list (APPEND RAW_BUILD_TOOLKITS ${BUILD_TOOLKIT} ${TOOLKIT_FULL_DEPS})
endforeach()
@@ -134,14 +250,28 @@ OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/occt_defs_flags")
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/3rdparty_macro")
# search for TKIVtk and TKIVtkDraw in BUILD_TOOLKITS
list (FIND BUILD_TOOLKITS TKIVtk CAN_USE_VTK)
if (CAN_USE_VTK EQUAL -1)
list (FIND BUILD_TOOLKITS TKIVtkDraw CAN_USE_VTK)
endif()
if (NOT CAN_USE_VTK EQUAL -1)
if (NOT DEFINED USE_VTK)
set (USE_VTK OFF CACHE BOOL "${USE_VTK_DESCR}")
endif()
else()
OCCT_CHECK_AND_UNSET (USE_VTK)
endif()
# Rebuild *.yacc and *.lex files that are contained by TKMath toolkit
list (FIND BUILD_TOOLKITS TKMath CAN_REBUILD_PDC_FOR_TKMATH)
list (FIND BUILD_TOOLKITS StepFile CAN_REBUILD_PDC_FOR_STEPFILE)
if (NOT ${CAN_REBUILD_PDC_FOR_TKMATH} EQUAL -1 OR NOT ${CAN_REBUILD_PDC_FOR_STEPFILE} EQUAL -1)
set (REBUILD_PLATFORM_DEPENDENT_CODE OFF CACHE BOOL "${REBUILD_PLATFORM_DEPENDENT_CODE_DESCR}")
set (BUILD_YACCLEX OFF CACHE BOOL "${BUILD_YACCLEX_DESCR}")
else()
OCCT_CHECK_AND_UNSET (REBUILD_PLATFORM_DEPENDENT_CODE)
OCCT_CHECK_AND_UNSET (BUILD_YACCLEX)
endif()
if (NOT DEFINED 3RDPARTY_DIR)
@@ -185,7 +315,13 @@ if (USE_VTK)
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/vtk")
else()
OCCT_CHECK_AND_UNSET_GROUP ("3RDPARTY_VTK")
#OCCT_CHECK_AND_UNSET ("INSTALL_VTK")
if (NOT CAN_USE_VTK EQUAL -1)
message (STATUS "Info: TKIVtk and TKIVtkDraw toolkits excluded due to VTK usage is disabled")
list (REMOVE_ITEM BUILD_TOOLKITS TKIVtk)
list (REMOVE_ITEM BUILD_TOOLKITS TKIVtkDraw)
endif()
endif()
# D3D
@@ -280,9 +416,12 @@ if (BUILD_DOC_OcctOverview)
endif()
if (INSTALL_DOC_OcctOverview)
install (DIRECTORY "${CMAKE_BINARY_DIR}/doc/overview" DESTINATION "${INSTALL_DIR}/doc")
install (DIRECTORY "${CMAKE_BINARY_DIR}/doc/overview" DESTINATION "${INSTALL_SHARE_DIR}/doc")
OCCT_INSTALL_FILE_OR_DIR ("dox/resources/overview.html" "${INSTALL_DIR}")
# create overview.html only for windows
if (WIN32)
OCCT_INSTALL_FILE_OR_DIR ("dox/resources/overview.html" "${INSTALL_SCRIPT_DIR}")
endif()
endif()
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/doxygen")
@@ -290,18 +429,18 @@ else()
OCCT_CHECK_AND_UNSET ("INSTALL_DOC_OcctOverview")
OCCT_CHECK_AND_UNSET ("3RDPARTY_DOXYGEN_EXECUTABLE")
OCCT_CHECK_AND_UNSET ("3RDPARTY_DOXYGEN_DOT_EXECUTABLE")
OCCT_CHECK_AND_UNSET ("3RDPARTY_DOT_EXECUTABLE")
endif()
# bison
if (REBUILD_PLATFORM_DEPENDENT_CODE)
if (BUILD_YACCLEX)
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/bison")
else()
OCCT_CHECK_AND_UNSET ("3RDPARTY_BISON_EXECUTABLE")
endif()
# flex
if (REBUILD_PLATFORM_DEPENDENT_CODE)
if (BUILD_YACCLEX)
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/flex")
else()
OCCT_CHECK_AND_UNSET ("3RDPARTY_FLEX_EXECUTABLE")
@@ -317,7 +456,7 @@ endif()
if (3RDPARTY_INCLUDE_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_INCLUDE_DIRS)
string (REGEX REPLACE ";" "\n\t" 3RDPARTY_INCLUDE_DIRS_WITH_ENDS "${3RDPARTY_INCLUDE_DIRS}")
message (STATUS "The directories containing 3rdparty headers: ${3RDPARTY_INCLUDE_DIRS_WITH_ENDS}")
message (STATUS "Info: The directories of 3rdparty headers: ${3RDPARTY_INCLUDE_DIRS_WITH_ENDS}")
include_directories (${3RDPARTY_INCLUDE_DIRS})
endif()
@@ -327,14 +466,10 @@ include_directories (${CMAKE_BINARY_DIR}/inc)
if (3RDPARTY_LIBRARY_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_LIBRARY_DIRS)
string (REGEX REPLACE ";" "\n\t" 3RDPARTY_LIBRARY_DIRS_WITH_ENDS "${3RDPARTY_LIBRARY_DIRS}")
message (STATUS "The directories containing 3rdparty libraries: ${3RDPARTY_LIBRARY_DIRS_WITH_ENDS}")
message (STATUS "Info: The directories of 3rdparty libraries: ${3RDPARTY_LIBRARY_DIRS_WITH_ENDS}")
link_directories (${3RDPARTY_LIBRARY_DIRS})
endif()
# Get all used variables: OS_WITH_BIT, COMPILER
OCCT_MAKE_OS_WITH_BITNESS()
OCCT_MAKE_COMPILER_SHORT_NAME()
# build directories
set (CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE "${CMAKE_BINARY_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
set (CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE "${CMAKE_BINARY_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
@@ -354,15 +489,6 @@ if (WIN32)
set (CMAKE_LIBRARY_OUTPUT_DIRECTORY_DEBUG "${CMAKE_BINARY_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
if ("${INSTALL_DIR}" STREQUAL "")
get_filename_component (CMAKE_BINARY_DIR_PARENT ${CMAKE_BINARY_DIR} DIRECTORY)
set (INSTALL_DIR "${CMAKE_BINARY_DIR_PARENT}/install" CACHE PATH "${INSTALL_DIR_DESCR}" FORCE)
set (CMAKE_INSTALL_PREFIX "${INSTALL_DIR}" CACHE INTERNAL "" FORCE )
message (STATUS "Info: INSTALL_DIR has been set as ${INSTALL_DIR}")
endif()
string(TIMESTAMP CURRENT_TIME "%H:%M:%S")
message (STATUS "\nInfo: \(${CURRENT_TIME}\) Start collecting all OCCT header files into ${CMAKE_BINARY_DIR}/inc ...")
@@ -372,15 +498,24 @@ COLLECT_AND_INSTALL_OCCT_HEADER_FILES ("${CMAKE_BINARY_DIR}" "${BUILD_TOOLKITS}"
string(TIMESTAMP CURRENT_TIME "%H:%M:%S")
message (STATUS "Info: \(${CURRENT_TIME}\) End the collecting")
OCCT_INSTALL_FILE_OR_DIR ("data" "${INSTALL_DIR}")
OCCT_INSTALL_FILE_OR_DIR ("samples/tcl" "${INSTALL_DIR}/samples")
OCCT_INSTALL_FILE_OR_DIR ("data" "${INSTALL_SHARE_DIR}")
if (INSTALL_OCCT_SAMPLES)
OCCT_INSTALL_FILE_OR_DIR ("samples" "${INSTALL_DIR}")
# OCCT samples
if (INSTALL_SAMPLES)
if (WIN32)
OCCT_INSTALL_FILE_OR_DIR ("samples/CSharp" "${INSTALL_SHARE_DIR}/samples")
OCCT_INSTALL_FILE_OR_DIR ("samples/mfc" "${INSTALL_SHARE_DIR}/samples")
endif()
OCCT_INSTALL_FILE_OR_DIR ("samples/java" "${INSTALL_SHARE_DIR}/samples")
OCCT_INSTALL_FILE_OR_DIR ("samples/ocafsamples" "${INSTALL_SHARE_DIR}/samples")
OCCT_INSTALL_FILE_OR_DIR ("samples/qt" "${INSTALL_SHARE_DIR}/samples")
endif()
if (INSTALL_OCCT_TEST_CASES)
OCCT_INSTALL_FILE_OR_DIR ("tests" "${INSTALL_DIR}")
OCCT_INSTALL_FILE_OR_DIR ("samples/tcl" "${INSTALL_SHARE_DIR}/samples")
if (INSTALL_TEST_CASES)
OCCT_INSTALL_FILE_OR_DIR ("tests" "${INSTALL_SHARE_DIR}")
endif()
if (WIN32)
@@ -389,14 +524,16 @@ else()
set (SCRIPT_EXT sh)
endif()
# DRAW.BAT or DRAW.SH
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/adm/templates/draw.${SCRIPT_EXT}")
install (FILES "${APPLY_OCCT_PATCH_DIR}/adm/templates/draw.${SCRIPT_EXT}" DESTINATION "${INSTALL_DIR}" PERMISSIONS
OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_WRITE GROUP_EXECUTE WORLD_READ WORLD_WRITE WORLD_EXECUTE)
# copy draw script to install script folder
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/adm/templates/draw.${SCRIPT_EXT}")
install (FILES "${BUILD_PATCH}/adm/templates/draw.${SCRIPT_EXT}" DESTINATION "${INSTALL_SCRIPT_DIR}"
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_WRITE GROUP_EXECUTE WORLD_READ WORLD_WRITE WORLD_EXECUTE)
else()
install (FILES "${CMAKE_SOURCE_DIR}/adm/templates/draw.${SCRIPT_EXT}" DESTINATION "${INSTALL_DIR}" PERMISSIONS
OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_WRITE GROUP_EXECUTE WORLD_READ WORLD_WRITE WORLD_EXECUTE)
install (FILES "${CMAKE_SOURCE_DIR}/adm/templates/draw.${SCRIPT_EXT}" DESTINATION "${INSTALL_SCRIPT_DIR}"
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_WRITE GROUP_EXECUTE WORLD_READ WORLD_WRITE WORLD_EXECUTE)
endif()
# copy draw script to CMake binary folder
OCCT_COPY_FILE_OR_DIR ("adm/templates/draw.${SCRIPT_EXT}" "${CMAKE_BINARY_DIR}")
set (SUB_CUSTOM_NAME "custom_${COMPILER}_${COMPILER_BITNESS}.${SCRIPT_EXT}")
@@ -404,29 +541,29 @@ set (SUB_CUSTOM_NAME "custom_${COMPILER}_${COMPILER_BITNESS}.${SCRIPT_EXT}")
if (WIN32)
set (ADDITIONAL_CUSTOM_CONTENT "\nif exist \"%~dp0${SUB_CUSTOM_NAME}\" (\n call \"%~dp0${SUB_CUSTOM_NAME}\" %VCVER% %ARCH% %CASDEB% \n)")
else()
set (ADDITIONAL_CUSTOM_CONTENT "\nif [ -e \"\${aScriptPath}/${SUB_CUSTOM_NAME}\" ]; then\n source \"\${aScriptPath}/${SUB_CUSTOM_NAME}\" \"\${COMPILER}\" \"\${WOKSTATION}\${ARCH}\" \"\${CASDEB}\" \nfi")
set (ADDITIONAL_CUSTOM_CONTENT "\nif [ -e \"\${aScriptPath}/${SUB_CUSTOM_NAME}\" ]; then\n source \"\${aScriptPath}/${SUB_CUSTOM_NAME}\" \"\$1\" \"\$2\" \nfi")
endif()
# change custom.bat/sh
if (EXISTS "${INSTALL_DIR}/custom.${SCRIPT_EXT}")
file (READ "${INSTALL_DIR}/custom.${SCRIPT_EXT}" CUSTOM_CONTENT)
if (EXISTS "${INSTALL_BIN_DIR}/custom.${SCRIPT_EXT}")
file (READ "${INSTALL_BIN_DIR}/custom.${SCRIPT_EXT}" CUSTOM_CONTENT)
set (CUSTOM_CONTENT "${CUSTOM_CONTENT} ${ADDITIONAL_CUSTOM_CONTENT}")
file (WRITE "${INSTALL_DIR}/custom.${SCRIPT_EXT}" "${CUSTOM_CONTENT}")
file (WRITE "${INSTALL_BIN_DIR}/custom.${SCRIPT_EXT}" "${CUSTOM_CONTENT}")
else()
OCCT_CONFIGURE_AND_INSTALL ("adm/templates/custom.${SCRIPT_EXT}.main" "custom.${SCRIPT_EXT}" "custom.${SCRIPT_EXT}" "${INSTALL_DIR}")
OCCT_CONFIGURE_AND_INSTALL ("adm/templates/custom.${SCRIPT_EXT}.main" "custom.${SCRIPT_EXT}" "custom.${SCRIPT_EXT}" "${INSTALL_SCRIPT_DIR}")
endif()
# write current custom.bat/sh (for install directory)
set (SUB_CUSTOM_BUILD_NAME "custom_${COMPILER}_${COMPILER_BITNESS}.install.${SCRIPT_EXT}")
OCCT_CONFIGURE_AND_INSTALL ("adm/templates/custom.install.${SCRIPT_EXT}.in" "${SUB_CUSTOM_BUILD_NAME}" "${SUB_CUSTOM_NAME}" "${INSTALL_DIR}")
OCCT_CONFIGURE_AND_INSTALL ("adm/templates/custom.install.${SCRIPT_EXT}.in" "${SUB_CUSTOM_BUILD_NAME}" "${SUB_CUSTOM_NAME}" "${INSTALL_SCRIPT_DIR}")
# write current custom.bat/sh (for build directory)
OCCT_CONFIGURE ("adm/templates/custom.build.${SCRIPT_EXT}.in" "${SUB_CUSTOM_NAME}")
if (BUILD_MODULE_OcctMfcSamples)
OCCT_INSTALL_FILE_OR_DIR ("adm/templates/sample.bat" "${INSTALL_DIR}")
OCCT_INSTALL_FILE_OR_DIR ("adm/templates/sample.bat" "${INSTALL_SCRIPT_DIR}")
OCCT_COPY_FILE_OR_DIR ("adm/templates/sample.bat" "${CMAKE_BINARY_DIR}")
endif()
@@ -434,29 +571,31 @@ endif()
OCCT_CONFIGURE ("adm/templates/env.build.${SCRIPT_EXT}.in" "env.${SCRIPT_EXT}")
# end script for draw in standalone environment
# release version
set (BUILD_LETTER "")
OCCT_CONFIGURE ("adm/templates/env.install.${SCRIPT_EXT}.in" "env.install.release.${SCRIPT_EXT}")
install (FILES "${CMAKE_BINARY_DIR}/env.install.release.${SCRIPT_EXT}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}"
RENAME "env.${SCRIPT_EXT}")
if (UNIX)
OCCT_CONFIGURE ("adm/templates/env.install.sh.in" "env.install.sh")
install (FILES "${CMAKE_BINARY_DIR}/env.install.sh" DESTINATION "${INSTALL_SCRIPT_DIR}" RENAME "env.sh")
else()
# release version
set (CURRENT_BUILD_LETTER "")
OCCT_CONFIGURE ("adm/templates/env.install.bat.in" "env.install.release.bat")
install (FILES "${CMAKE_BINARY_DIR}/env.install.release.bat"
CONFIGURATIONS Release
DESTINATION "${INSTALL_SCRIPT_DIR}" RENAME "env.bat")
# debug version
set (BUILD_LETTER "d")
OCCT_CONFIGURE ("adm/templates/env.install.${SCRIPT_EXT}.in" "env.install.debug.${SCRIPT_EXT}")
install (FILES "${CMAKE_BINARY_DIR}/env.install.debug.${SCRIPT_EXT}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}"
RENAME "env.${SCRIPT_EXT}")
# debug version
set (CURRENT_BUILD_LETTER "d")
OCCT_CONFIGURE ("adm/templates/env.install.bat.in" "env.install.debug.bat")
install (FILES "${CMAKE_BINARY_DIR}/env.install.debug.bat"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_SCRIPT_DIR}" RENAME "env.bat")
# release with debug info version
set (BUILD_LETTER "i")
OCCT_CONFIGURE ("adm/templates/env.install.${SCRIPT_EXT}.in" "env.install.relwithdebinfo.${SCRIPT_EXT}")
install (FILES "${CMAKE_BINARY_DIR}/env.install.relwithdebinfo.${SCRIPT_EXT}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}"
RENAME "env.${SCRIPT_EXT}")
# release with debug info version
set (CURRENT_BUILD_LETTER "i")
OCCT_CONFIGURE ("adm/templates/env.install.bat.in" "env.install.relwithdebinfo.bat")
install (FILES "${CMAKE_BINARY_DIR}/env.install.relwithdebinfo.bat"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_SCRIPT_DIR}" RENAME "env.bat")
endif()
# copy DrawAppliInit from OCCT source to build directory
if (NOT EXISTS "${CMAKE_BINARY_DIR}/DrawAppliInit")
@@ -469,9 +608,9 @@ foreach(RESOURCE ${RESOURCES})
get_filename_component(RESOURCE_FOLDER ${RESOURCE} DIRECTORY)
if(NOT "${RESOURCE_FOLDER}" STREQUAL "")
get_filename_component(RESOURCE_FOLDER ${RESOURCE_FOLDER} NAME)
OCCT_INSTALL_FILE_OR_DIR ("src/${RESOURCE}" "${INSTALL_DIR}/src/${RESOURCE_FOLDER}")
OCCT_INSTALL_FILE_OR_DIR ("src/${RESOURCE}" "${INSTALL_OCCT_RESOURCE_DIR}/${RESOURCE_FOLDER}")
else()
OCCT_INSTALL_FILE_OR_DIR ("src/${RESOURCE}" "${INSTALL_DIR}/src")
OCCT_INSTALL_FILE_OR_DIR ("src/${RESOURCE}" "${INSTALL_OCCT_RESOURCE_DIR}")
endif()
endforeach()

View File

@@ -2,6 +2,6 @@ FoundationClasses TKernel TKMath
ModelingData TKG2d TKG3d TKGeomBase TKBRep
ModelingAlgorithms TKGeomAlgo TKTopAlgo TKPrim TKBO TKBool TKHLR TKFillet TKOffset TKFeat TKMesh TKXMesh TKShHealing
Visualization TKService TKV3d TKOpenGl TKMeshVS TKIVtk TKD3DHost
ApplicationFramework TKCDF TKLCAF TKCAF TKBinL TKXmlL TKBin TKXml FWOSPlugin TKTObj TKBinTObj TKXmlTObj
ApplicationFramework TKCDF TKLCAF TKCAF TKBinL TKXmlL TKBin TKXml TKStdL TKStd TKShape FWOSPlugin TKTObj TKBinTObj TKXmlTObj TKVCAF
DataExchange TKXSBase TKSTEPBase TKSTEPAttr TKSTEP209 TKSTEP TKIGES TKXCAF TKXDEIGES TKXDESTEP TKSTL TKVRML TKXmlXCAF TKBinXCAF
Draw TKDraw TKTopTest TKViewerTest TKXSDRAW TKDCAF TKXDEDRAW TKTObjDRAW TKQADraw TKIVtkDraw DRAWEXE
Draw TKDraw TKTopTest TKViewerTest TKXSDRAW TKDCAF TKXDEDRAW TKTObjDRAW TKQADraw TKIVtkDraw DRAWEXE

View File

@@ -237,13 +237,18 @@ n BinMDataXtd
n BinMDocStd
n BinMFunction
n BinMNaming
n BinMPrsStd
n BinObjMgt
n BinTools
n CDF
n CDM
n FWOSDriver
n PCDM
n StdLDrivers
n StdLPersistent
n StdObjMgt
n StdDrivers
n StdPersistent
n ShapePersistent
n TDF
n TDataStd
n TDataXtd
@@ -260,7 +265,6 @@ n XmlMDataXtd
n XmlMDocStd
n XmlMFunction
n XmlMNaming
n XmlMPrsStd
n XmlObjMgt
r StdResource
r XmlOcafResource
@@ -273,6 +277,9 @@ t TKCAF
t TKCDF
t TKLCAF
t TKStdL
t TKStd
t TKShape
t TKTObj
t TKXml
t TKXmlL
@@ -431,3 +438,5 @@ n IVtkTools
t TKIVtk
n IVtkDraw
t TKIVtkDraw
n Geom2dEvaluator
t TKVCAF

View File

@@ -191,47 +191,62 @@ macro (THIRDPARTY_PRODUCT PRODUCT_NAME HEADER_NAME LIBRARY_NAME LIBRARY_NAME_DEB
OCCT_MAKE_COMPILER_SHORT_NAME()
if (WIN32)
install (FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
if (DEFINED INSTALL_BIN_DIR)
install (FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}" DESTINATION "${INSTALL_BIN_DIR}")
else()
install (FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
else()
get_filename_component(ABS_PATH ${3RDPARTY_${PRODUCT_NAME}_LIBRARY} REALPATH)
if ("${PRODUCT_NAME}" STREQUAL "FREEIMAGE")
get_filename_component(FREEIMLIB ${3RDPARTY_${PRODUCT_NAME}_LIBRARY} NAME)
install (FILES "${ABS_PATH}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${FREEIMLIB}.3)
install (FILES "${ABS_PATH}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${FREEIMLIB}.3)
install (FILES "${ABS_PATH}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${FREEIMLIB}.3)
if (DEFINED INSTALL_LIB_DIR)
install (FILES "${ABS_PATH}" DESTINATION "${INSTALL_LIB_DIR}" RENAME ${FREEIMLIB}.3)
else()
install (FILES "${ABS_PATH}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${FREEIMLIB}.3)
install (FILES "${ABS_PATH}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${FREEIMLIB}.3)
install (FILES "${ABS_PATH}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${FREEIMLIB}.3)
endif()
endif()
if("${PRODUCT_NAME}" STREQUAL "GL2PS")
get_filename_component(GL2PSLIB ${3RDPARTY_${PRODUCT_NAME}_LIBRARY} NAME)
install (FILES "${ABS_PATH}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${GL2PSLIB}.1)
install (FILES "${ABS_PATH}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${GL2PSLIB}.1)
install (FILES "${ABS_PATH}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${GL2PSLIB}.1)
if (DEFINED INSTALL_LIB_DIR)
install (FILES "${ABS_PATH}" DESTINATION "${INSTALL_LIB_DIR}" RENAME ${GL2PSLIB}.1)
else()
install (FILES "${ABS_PATH}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${GL2PSLIB}.1)
install (FILES "${ABS_PATH}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${GL2PSLIB}.1)
install (FILES "${ABS_PATH}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${GL2PSLIB}.1)
endif()
endif()
endif()
else()

View File

@@ -1,32 +1,35 @@
# doxygen
set (3RDPARTY_DOT_EXECUTABLE_DESCR "The path to the 'dot' tool producing layered drawings of directed graphs.\nThis tool used by doxygen")
set (3RDPARTY_DOXYGEN_EXECUTABLE_DESCR "The path to the doxygen command")
if (NOT DEFINED 3RDPARTY_DOXYGEN_EXECUTABLE)
set (3RDPARTY_DOXYGEN_EXECUTABLE "" CACHE FILEPATH "The Path to the doxygen command")
set (3RDPARTY_DOXYGEN_EXECUTABLE "" CACHE FILEPATH "${3RDPARTY_DOXYGEN_EXECUTABLE_DESCR}")
endif()
if (NOT DEFINED 3RDPARTY_DOXYGEN_DOT_EXECUTABLE)
set (3RDPARTY_DOXYGEN_DOT_EXECUTABLE "" CACHE FILEPATH "The path to the dot program used by doxygen")
if (NOT DEFINED 3RDPARTY_DOT_EXECUTABLE)
set (3RDPARTY_DOT_EXECUTABLE "" CACHE FILEPATH "${3RDPARTY_DOT_EXECUTABLE_DESCR}")
endif()
if (NOT DEFINED 3RDPARTY_DOXYGEN_SKIP_DOT_EXECUTABLE)
set (3RDPARTY_DOXYGEN_SKIP_DOT_EXECUTABLE OFF CACHE BOOL "Skip trying to find Dot")
if (NOT DEFINED 3RDPARTY_SKIP_DOT_EXECUTABLE)
set (3RDPARTY_SKIP_DOT_EXECUTABLE OFF CACHE BOOL "Skip trying to find Dot")
endif()
if (3RDPARTY_DOXYGEN_SKIP_DOT_EXECUTABLE)
OCCT_CHECK_AND_UNSET (3RDPARTY_DOXYGEN_DOT_EXECUTABLE)
if (3RDPARTY_SKIP_DOT_EXECUTABLE)
OCCT_CHECK_AND_UNSET (3RDPARTY_DOT_EXECUTABLE)
endif()
if (NOT 3RDPARTY_DOXYGEN_EXECUTABLE OR (NOT 3RDPARTY_DOXYGEN_SKIP_DOT_EXECUTABLE AND NOT 3RDPARTY_DOXYGEN_DOT_EXECUTABLE))
if (NOT 3RDPARTY_DOXYGEN_EXECUTABLE OR (NOT 3RDPARTY_SKIP_DOT_EXECUTABLE AND NOT 3RDPARTY_DOT_EXECUTABLE))
set (DOXYGEN_SKIP_DOT ${3RDPARTY_DOXYGEN_SKIP_DOT_EXECUTABLE})
set (DOXYGEN_SKIP_DOT ${3RDPARTY_SKIP_DOT_EXECUTABLE})
find_package (Doxygen)
if (NOT 3RDPARTY_DOXYGEN_EXECUTABLE AND DOXYGEN_EXECUTABLE)
set (3RDPARTY_DOXYGEN_EXECUTABLE "${DOXYGEN_EXECUTABLE}" CACHE FILEPATH "The Path to the doxygen command" FORCE)
set (3RDPARTY_DOXYGEN_EXECUTABLE "${DOXYGEN_EXECUTABLE}" CACHE FILEPATH "${3RDPARTY_DOXYGEN_EXECUTABLE_DESCR}" FORCE)
endif()
if (NOT 3RDPARTY_DOXYGEN_SKIP_DOT_EXECUTABLE AND NOT 3RDPARTY_DOXYGEN_DOT_EXECUTABLE AND DOXYGEN_DOT_EXECUTABLE)
set (3RDPARTY_DOXYGEN_DOT_EXECUTABLE "${DOXYGEN_DOT_EXECUTABLE}" CACHE FILEPATH "The path to the dot program used by doxygen" FORCE)
if (NOT 3RDPARTY_SKIP_DOT_EXECUTABLE AND NOT 3RDPARTY_DOT_EXECUTABLE AND DOXYGEN_DOT_EXECUTABLE)
set (3RDPARTY_DOT_EXECUTABLE "${DOXYGEN_DOT_EXECUTABLE}" CACHE FILEPATH "${3RDPARTY_DOT_EXECUTABLE_DESCR}" FORCE)
endif()
endif()
@@ -34,9 +37,9 @@ if (NOT 3RDPARTY_DOXYGEN_EXECUTABLE OR NOT EXISTS "${3RDPARTY_DOXYGEN_EXECUTABLE
list (APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_DOXYGEN_EXECUTABLE)
endif()
if (NOT 3RDPARTY_DOXYGEN_SKIP_DOT_EXECUTABLE)
if (NOT 3RDPARTY_DOXYGEN_DOT_EXECUTABLE OR NOT EXISTS "${3RDPARTY_DOXYGEN_DOT_EXECUTABLE}")
list (APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_DOXYGEN_DOT_EXECUTABLE)
if (NOT 3RDPARTY_SKIP_DOT_EXECUTABLE)
if (NOT 3RDPARTY_DOT_EXECUTABLE OR NOT EXISTS "${3RDPARTY_DOT_EXECUTABLE}")
list (APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_DOT_EXECUTABLE)
endif()
endif()

View File

@@ -289,34 +289,44 @@ endif()
# install instructions
if (INSTALL_FREETYPE)
OCCT_MAKE_OS_WITH_BITNESS()
if (WIN32)
install (FILES "${3RDPARTY_FREETYPE_DLL}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES "${3RDPARTY_FREETYPE_DLL}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES "${3RDPARTY_FREETYPE_DLL}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
if (DEFINED INSTALL_BIN_DIR)
install (FILES "${3RDPARTY_FREETYPE_DLL}" DESTINATION "${INSTALL_BIN_DIR}")
else()
install (FILES "${3RDPARTY_FREETYPE_DLL}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES "${3RDPARTY_FREETYPE_DLL}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES "${3RDPARTY_FREETYPE_DLL}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
else()
get_filename_component(3RDPARTY_FREETYPE_LIBRARY_ABS ${3RDPARTY_FREETYPE_LIBRARY} REALPATH)
get_filename_component(3RDPARTY_FREETYPE_LIBRARY_NAME ${3RDPARTY_FREETYPE_LIBRARY} NAME)
install (FILES "${3RDPARTY_FREETYPE_LIBRARY_ABS}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${3RDPARTY_FREETYPE_LIBRARY_NAME}.6)
install (FILES "${3RDPARTY_FREETYPE_LIBRARY_ABS}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${3RDPARTY_FREETYPE_LIBRARY_NAME}.6)
install (FILES "${3RDPARTY_FREETYPE_LIBRARY_ABS}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${3RDPARTY_FREETYPE_LIBRARY_NAME}.6)
if (DEFINED INSTALL_LIB_DIR)
install (FILES "${3RDPARTY_FREETYPE_LIBRARY_ABS}"
DESTINATION "${INSTALL_LIB_DIR}"
RENAME ${3RDPARTY_FREETYPE_LIBRARY_NAME}.6)
else()
install (FILES "${3RDPARTY_FREETYPE_LIBRARY_ABS}"
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${3RDPARTY_FREETYPE_LIBRARY_NAME}.6)
install (FILES "${3RDPARTY_FREETYPE_LIBRARY_ABS}"
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${3RDPARTY_FREETYPE_LIBRARY_NAME}.6)
install (FILES "${3RDPARTY_FREETYPE_LIBRARY_ABS}"
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${3RDPARTY_FREETYPE_LIBRARY_NAME}.6)
endif()
endif()
set (USED_3RDPARTY_FREETYPE_DIR "")

View File

@@ -12,20 +12,16 @@ endif()
if (USE_TCL)
if ("${3RDPARTY_TCL_LIBRARY_VERSION}" STREQUAL "")
message (STATUS "Warning. TCL version has not been specified by CSF_TclLibs defining thus it will be used as 8.6")
message (STATUS "Warning: TCL version has not been specified by CSF_TclLibs defining thus it will be used as 8.6")
set (3RDPARTY_TCL_LIBRARY_VERSION "8.6")
endif()
if ("${3RDPARTY_TK_LIBRARY_VERSION}" STREQUAL "")
message (STATUS "Warning. TK version has not been specified by CSF_TclTkLibs defining thus it will be used as 8.6")
message (STATUS "Warning: TK version has not been specified by CSF_TclTkLibs defining thus it will be used as 8.6")
set (3RDPARTY_TK_LIBRARY_VERSION "8.6")
endif()
endif()
if (USE_VTK AND NOT 3RDPARTY_VTK_REQUIRED_LIBRARIES)
message (WARNING "CSF_VTK specification: VTK libraries are not defined")
endif()
if (USE_TBB)
set (CSF_TBB "tbb tbbmalloc")
else()
@@ -45,12 +41,6 @@ if (WIN32)
set (CSF_TclTkLibs "tk${3RDPARTY_TK_LIBRARY_VERSION}.lib")
endif()
if (USE_VTK)
set (CSF_VTK "${3RDPARTY_VTK_REQUIRED_LIBRARIES}")
else()
set (CSF_VTK)
endif()
else()
if (APPLE)
@@ -84,7 +74,7 @@ else()
set (CSF_ThreadLibs "c")
set (CSF_OpenGlLibs "EGL GLESv2")
elseif (UNIX)
set (CSF_ThreadLibs "pthread rt")
set (CSF_ThreadLibs "pthread rt stdc++")
set (CSF_OpenGlLibs "GLU GL")
set (CSF_XwLibs "X11 Xext Xmu Xi")
@@ -113,10 +103,4 @@ else()
set (CSF_GL2PS)
endif()
endif()
if (USE_VTK)
set (CSF_VTK "${3RDPARTY_VTK_REQUIRED_LIBRARIES}")
else()
set (CSF_VTK)
endif()
endif()

View File

@@ -37,41 +37,41 @@ endif()
# remove _WINDOWS flag if it exists
string (REGEX MATCH "/D_WINDOWS" IS_WINDOWSFLAG "${CMAKE_CXX_FLAGS}")
if (IS_WINDOWSFLAG)
message (STATUS "/D_WINDOWS has been removed from CMAKE_CXX_FLAGS")
message (STATUS "Info: /D_WINDOWS has been removed from CMAKE_CXX_FLAGS")
string (REGEX REPLACE "/D_WINDOWS" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
endif()
# remove WIN32 flag if it exists
string (REGEX MATCH "/DWIN32" IS_WIN32FLAG "${CMAKE_CXX_FLAGS}")
if (IS_WIN32FLAG)
message (STATUS "/DWIN32 has been removed from CMAKE_CXX_FLAGS")
message (STATUS "Info: /DWIN32 has been removed from CMAKE_CXX_FLAGS")
string (REGEX REPLACE "/DWIN32" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
endif()
# remove _WINDOWS flag if it exists
string (REGEX MATCH "/D_WINDOWS" IS_WINDOWSFLAG "${CMAKE_C_FLAGS}")
if (IS_WINDOWSFLAG)
message (STATUS "/D_WINDOWS has been removed from CMAKE_C_FLAGS")
message (STATUS "Info: /D_WINDOWS has been removed from CMAKE_C_FLAGS")
string (REGEX REPLACE "/D_WINDOWS" "" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
endif()
# remove WIN32 flag if it exists
string (REGEX MATCH "/DWIN32" IS_WIN32FLAG "${CMAKE_C_FLAGS}")
if (IS_WIN32FLAG)
message (STATUS "/DWIN32 has been removed from CMAKE_C_FLAGS")
message (STATUS "Info: /DWIN32 has been removed from CMAKE_C_FLAGS")
string (REGEX REPLACE "/DWIN32" "" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
endif()
# remove DEBUG flag if it exists
string (REGEX MATCH "-DDEBUG" IS_DEBUG_CXX "${CMAKE_CXX_FLAGS_DEBUG}")
if (IS_DEBUG_CXX)
message (STATUS "-DDEBUG has been removed from CMAKE_CXX_FLAGS_DEBUG")
message (STATUS "Info: -DDEBUG has been removed from CMAKE_CXX_FLAGS_DEBUG")
string (REGEX REPLACE "-DDEBUG" "" CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}")
endif()
string (REGEX MATCH "-DDEBUG" IS_DEBUG_C "${CMAKE_C_FLAGS_DEBUG}")
if (IS_DEBUG_C)
message (STATUS "-DDEBUG has been removed from CMAKE_C_FLAGS_DEBUG")
message (STATUS "Info: -DDEBUG has been removed from CMAKE_C_FLAGS_DEBUG")
string (REGEX REPLACE "-DDEBUG" "" CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG}")
endif()
# enable parallel compilation on MSVC 9 and above

View File

@@ -91,18 +91,18 @@ endfunction()
function (OCCT_ORIGIN_AND_PATCHED_FILES RELATIVE_PATH SEARCH_TEMPLATE RESULT)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${RELATIVE_PATH}")
file (GLOB FOUND_FILES "${APPLY_OCCT_PATCH_DIR}/${RELATIVE_PATH}/${SEARCH_TEMPLATE}")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${RELATIVE_PATH}")
file (GLOB FOUND_FILES "${BUILD_PATCH}/${RELATIVE_PATH}/${SEARCH_TEMPLATE}")
endif()
file (GLOB ORIGIN_FILES "${CMAKE_SOURCE_DIR}/${RELATIVE_PATH}/${SEARCH_TEMPLATE}")
foreach (ORIGIN_FILE ${ORIGIN_FILES})
# check for existence of patched version of current file
if (NOT APPLY_OCCT_PATCH_DIR OR NOT EXISTS "${APPLY_OCCT_PATCH_DIR}/${RELATIVE_PATH}")
if (NOT BUILD_PATCH OR NOT EXISTS "${BUILD_PATCH}/${RELATIVE_PATH}")
list (APPEND FOUND_FILES ${ORIGIN_FILE})
else()
get_filename_component (ORIGIN_FILE_NAME "${ORIGIN_FILE}" NAME)
if (NOT EXISTS "${APPLY_OCCT_PATCH_DIR}/${RELATIVE_PATH}/${ORIGIN_FILE_NAME}")
if (NOT EXISTS "${BUILD_PATCH}/${RELATIVE_PATH}/${ORIGIN_FILE_NAME}")
list (APPEND FOUND_FILES ${ORIGIN_FILE})
endif()
endif()
@@ -147,15 +147,15 @@ function (FIND_PRODUCT_DIR ROOT_DIR PRODUCT_NAME RESULT)
endfunction()
macro (OCCT_INSTALL_FILE_OR_DIR BEING_INSTALLED_OBJECT DESTINATION_PATH)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${BEING_INSTALLED_OBJECT}")
if (IS_DIRECTORY "${APPLY_OCCT_PATCH_DIR}/${BEING_INSTALLED_OBJECT}")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${BEING_INSTALLED_OBJECT}")
if (IS_DIRECTORY "${BUILD_PATCH}/${BEING_INSTALLED_OBJECT}")
# first of all, install original files
install (DIRECTORY "${CMAKE_SOURCE_DIR}/${BEING_INSTALLED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
# secondly, rewrite original files with patched ones
install (DIRECTORY "${APPLY_OCCT_PATCH_DIR}/${BEING_INSTALLED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
install (DIRECTORY "${BUILD_PATCH}/${BEING_INSTALLED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
else()
install (FILES "${APPLY_OCCT_PATCH_DIR}/${BEING_INSTALLED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
install (FILES "${BUILD_PATCH}/${BEING_INSTALLED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
endif()
else()
if (IS_DIRECTORY "${CMAKE_SOURCE_DIR}/${BEING_INSTALLED_OBJECT}")
@@ -167,8 +167,8 @@ macro (OCCT_INSTALL_FILE_OR_DIR BEING_INSTALLED_OBJECT DESTINATION_PATH)
endmacro()
macro (OCCT_CONFIGURE_AND_INSTALL BEING_CONGIRUGED_FILE BUILD_NAME INSTALL_NAME DESTINATION_PATH)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${BEING_CONGIRUGED_FILE}")
configure_file("${APPLY_OCCT_PATCH_DIR}/${BEING_CONGIRUGED_FILE}" "${BUILD_NAME}" @ONLY)
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${BEING_CONGIRUGED_FILE}")
configure_file("${BUILD_PATCH}/${BEING_CONGIRUGED_FILE}" "${BUILD_NAME}" @ONLY)
else()
configure_file("${CMAKE_SOURCE_DIR}/${BEING_CONGIRUGED_FILE}" "${BUILD_NAME}" @ONLY)
endif()
@@ -181,8 +181,8 @@ macro (COLLECT_AND_INSTALL_OCCT_HEADER_FILES ROOT_TARGET_OCCT_DIR OCCT_BUILD_TOO
# consider patched header.in template
set (TEMPLATE_HEADER_PATH "${CMAKE_SOURCE_DIR}/adm/templates/header.in")
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/adm/templates/header.in")
set (TEMPLATE_HEADER_PATH "${APPLY_OCCT_PATCH_DIR}/adm/templates/header.in")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/adm/templates/header.in")
set (TEMPLATE_HEADER_PATH "${BUILD_PATCH}/adm/templates/header.in")
endif()
set (ROOT_OCCT_DIR ${CMAKE_SOURCE_DIR})
@@ -190,8 +190,8 @@ macro (COLLECT_AND_INSTALL_OCCT_HEADER_FILES ROOT_TARGET_OCCT_DIR OCCT_BUILD_TOO
foreach (OCCT_USED_TOOLKIT ${OCCT_BUILD_TOOLKITS})
# append all required package folders
set (OCCT_TOOLKIT_PACKAGES)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_USED_TOOLKIT}/PACKAGES")
file (STRINGS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_USED_TOOLKIT}/PACKAGES" OCCT_TOOLKIT_PACKAGES)
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/src/${OCCT_USED_TOOLKIT}/PACKAGES")
file (STRINGS "${BUILD_PATCH}/src/${OCCT_USED_TOOLKIT}/PACKAGES" OCCT_TOOLKIT_PACKAGES)
elseif (EXISTS "${CMAKE_SOURCE_DIR}/src/${OCCT_USED_TOOLKIT}/PACKAGES")
file (STRINGS "${CMAKE_SOURCE_DIR}/src/${OCCT_USED_TOOLKIT}/PACKAGES" OCCT_TOOLKIT_PACKAGES)
endif()
@@ -206,7 +206,7 @@ macro (COLLECT_AND_INSTALL_OCCT_HEADER_FILES ROOT_TARGET_OCCT_DIR OCCT_BUILD_TOO
set (OCCT_HEADER_FILE_WITH_PROPER_NAMES)
string(TIMESTAMP CURRENT_TIME "%H:%M:%S")
message (STATUS "Info. \(${CURRENT_TIME}\) Compare FILES with files in package directories...")
message (STATUS "Info: \(${CURRENT_TIME}\) Compare FILES with files in package directories...")
foreach (OCCT_PACKAGE ${OCCT_USED_PACKAGES})
if (EXISTS "${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/FILES")
@@ -252,7 +252,7 @@ macro (COLLECT_AND_INSTALL_OCCT_HEADER_FILES ROOT_TARGET_OCCT_DIR OCCT_BUILD_TOO
endforeach()
if (NOT OCCT_FILE_IN_DIR_STATUS)
message (STATUS "Warning. ${OCCT_FILE_IN_DIR} is not involved into ${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/FILES")
message (STATUS "Warning. File ${OCCT_FILE_IN_DIR} is not listed in ${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/FILES")
string (REGEX MATCH ".+\\.[hlg]xx|.+\\.h$" IS_HEADER_FOUND "${OCCT_FILE_NAME}")
if (IS_HEADER_FOUND)
@@ -267,17 +267,17 @@ macro (COLLECT_AND_INSTALL_OCCT_HEADER_FILES ROOT_TARGET_OCCT_DIR OCCT_BUILD_TOO
# create new file including found header
string(TIMESTAMP CURRENT_TIME "%H:%M:%S")
message (STATUS "Info. \(${CURRENT_TIME}\) Create header-links in inc folder...")
message (STATUS "Info: \(${CURRENT_TIME}\) Create header-links in inc folder...")
foreach (OCCT_HEADER_FILE ${OCCT_HEADER_FILES_COMPLETE})
get_filename_component (HEADER_FILE_NAME ${OCCT_HEADER_FILE} NAME)
configure_file ("${TEMPLATE_HEADER_PATH}" "${ROOT_TARGET_OCCT_DIR}/inc/${HEADER_FILE_NAME}" @ONLY)
endforeach()
install (FILES ${OCCT_HEADER_FILES_COMPLETE} DESTINATION "${INSTALL_DIR}/inc")
install (FILES ${OCCT_HEADER_FILES_COMPLETE} DESTINATION "${INSTALL_INCLUDE_DIR}")
string(TIMESTAMP CURRENT_TIME "%H:%M:%S")
message (STATUS "Info. \(${CURRENT_TIME}\) Checking headers in inc folder...")
message (STATUS "Info: \(${CURRENT_TIME}\) Checking headers in inc folder...")
file (GLOB OCCT_HEADER_FILES_OLD "${ROOT_TARGET_OCCT_DIR}/inc/*")
foreach (OCCT_HEADER_FILE_OLD ${OCCT_HEADER_FILES_OLD})
@@ -316,23 +316,23 @@ macro (OCCT_COPY_FILE_OR_DIR BEING_COPIED_OBJECT DESTINATION_PATH)
file (COPY "${CMAKE_SOURCE_DIR}/${BEING_COPIED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
endif()
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${BEING_COPIED_OBJECT}")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${BEING_COPIED_OBJECT}")
# secondly, rewrite original files with patched ones
file (COPY "${APPLY_OCCT_PATCH_DIR}/${BEING_COPIED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
file (COPY "${BUILD_PATCH}/${BEING_COPIED_OBJECT}" DESTINATION "${DESTINATION_PATH}")
endif()
endmacro()
macro (OCCT_CONFIGURE BEING_CONGIRUGED_FILE FINAL_NAME)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${BEING_CONGIRUGED_FILE}")
configure_file("${APPLY_OCCT_PATCH_DIR}/${BEING_CONGIRUGED_FILE}" "${FINAL_NAME}" @ONLY)
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${BEING_CONGIRUGED_FILE}")
configure_file("${BUILD_PATCH}/${BEING_CONGIRUGED_FILE}" "${FINAL_NAME}" @ONLY)
else()
configure_file("${CMAKE_SOURCE_DIR}/${BEING_CONGIRUGED_FILE}" "${FINAL_NAME}" @ONLY)
endif()
endmacro()
macro (OCCT_ADD_SUBDIRECTORY BEING_ADDED_DIRECTORY)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${BEING_ADDED_DIRECTORY}/CMakeLists.txt")
add_subdirectory(${APPLY_OCCT_PATCH_DIR}/${BEING_ADDED_DIRECTORY})
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${BEING_ADDED_DIRECTORY}/CMakeLists.txt")
add_subdirectory(${BUILD_PATCH}/${BEING_ADDED_DIRECTORY})
elseif (EXISTS "${CMAKE_SOURCE_DIR}/${BEING_ADDED_DIRECTORY}/CMakeLists.txt")
add_subdirectory (${CMAKE_SOURCE_DIR}/${BEING_ADDED_DIRECTORY})
else()
@@ -347,8 +347,8 @@ function (OCCT_IS_PRODUCT_REQUIRED CSF_VAR_NAME USE_PRODUCT)
message(STATUS "Warning: the list of being used toolkits is empty")
else()
foreach (USED_TOOLKIT ${BUILD_TOOLKITS})
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/src/${USED_TOOLKIT}/EXTERNLIB")
file (READ "${APPLY_OCCT_PATCH_DIR}/src/${USED_TOOLKIT}/EXTERNLIB" FILE_CONTENT)
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/src/${USED_TOOLKIT}/EXTERNLIB")
file (READ "${BUILD_PATCH}/src/${USED_TOOLKIT}/EXTERNLIB" FILE_CONTENT)
elseif (EXISTS "${CMAKE_SOURCE_DIR}/src/${USED_TOOLKIT}/EXTERNLIB")
file (READ "${CMAKE_SOURCE_DIR}/src/${USED_TOOLKIT}/EXTERNLIB" FILE_CONTENT)
endif()
@@ -365,8 +365,8 @@ endfunction()
function (FILE_TO_LIST FILE_NAME FILE_CONTENT)
set (LOCAL_FILE_CONTENT)
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/${FILE_NAME}")
file (STRINGS "${APPLY_OCCT_PATCH_DIR}/${FILE_NAME}" LOCAL_FILE_CONTENT)
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/${FILE_NAME}")
file (STRINGS "${BUILD_PATCH}/${FILE_NAME}" LOCAL_FILE_CONTENT)
elseif (EXISTS "${CMAKE_SOURCE_DIR}/${FILE_NAME}")
file (STRINGS "${CMAKE_SOURCE_DIR}/${FILE_NAME}" LOCAL_FILE_CONTENT)
endif()
@@ -457,28 +457,42 @@ function (OCCT_MODULES_AND_TOOLKITS MODULE_LIST)
set (${MODULE_LIST} ${${MODULE_LIST}} PARENT_SCOPE)
endfunction()
# Returns OCCT version string from file Standard_Version.hxx (if available)
function (OCCT_VERSION OCCT_VERSION_VAR)
set (OCC_VERSION_COMPLETE "7.1.0")
set (OCC_VERSION_DEVELOPMENT "")
set (OCCT_VERSION_LOCALVAR "${OCC_VERSION_COMPLETE}.${OCC_VERSION_DEVELOPMENT}")
# Returns OCC version string from file Standard_Version.hxx (if available)
function (OCC_VERSION OCC_VERSION_MAJOR OCC_VERSION_MINOR OCC_VERSION_MAINTENANCE OCC_VERSION_DEVELOPMENT OCC_VERSION_STRING_EXT)
set (OCC_VERSION_MAJOR 7)
set (OCC_VERSION_MINOR 0)
set (OCC_VERSION_MAINTENANCE 0)
set (OCC_VERSION_DEVELOPMENT dev)
set (OCC_VERSION_COMPLETE "7.0.0")
set (STANDARD_VERSION_FILE "${CMAKE_SOURCE_DIR}/src/Standard/Standard_Version.hxx")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/src/Standard/Standard_Version.hxx")
set (STANDARD_VERSION_FILE "${BUILD_PATCH}/src/Standard/Standard_Version.hxx")
endif()
if (EXISTS "${STANDARD_VERSION_FILE}")
foreach (SOUGHT_VERSION OCC_VERSION_COMPLETE OCC_VERSION_DEVELOPMENT)
foreach (SOUGHT_VERSION OCC_VERSION_MAJOR OCC_VERSION_MINOR OCC_VERSION_MAINTENANCE)
file (STRINGS "${STANDARD_VERSION_FILE}" ${SOUGHT_VERSION} REGEX "^#define ${SOUGHT_VERSION} .*")
string (REGEX REPLACE ".*${SOUGHT_VERSION} .*([^ ]+).*" "\\1" ${SOUGHT_VERSION} "${${SOUGHT_VERSION}}" )
endforeach()
foreach (SOUGHT_VERSION OCC_VERSION_DEVELOPMENT OCC_VERSION_COMPLETE)
file (STRINGS "${STANDARD_VERSION_FILE}" ${SOUGHT_VERSION} REGEX "^#define ${SOUGHT_VERSION} .*")
string (REGEX REPLACE ".*${SOUGHT_VERSION} .*\"([^ ]+)\".*" "\\1" ${SOUGHT_VERSION} "${${SOUGHT_VERSION}}" )
endforeach()
if (NOT "${OCC_VERSION_DEVELOPMENT}" STREQUAL "")
set (OCCT_VERSION_LOCALVAR "${OCC_VERSION_COMPLETE}.${OCC_VERSION_DEVELOPMENT}")
else()
set (OCCT_VERSION_LOCALVAR "${OCC_VERSION_COMPLETE}")
endif()
endif()
set (${OCCT_VERSION_VAR} "${OCCT_VERSION_LOCALVAR}" PARENT_SCOPE)
set (OCC_VERSION_MAJOR "${OCC_VERSION_MAJOR}" PARENT_SCOPE)
set (OCC_VERSION_MINOR "${OCC_VERSION_MINOR}" PARENT_SCOPE)
set (OCC_VERSION_MAINTENANCE "${OCC_VERSION_MAINTENANCE}" PARENT_SCOPE)
set (OCC_VERSION_DEVELOPMENT "${OCC_VERSION_DEVELOPMENT}" PARENT_SCOPE)
if (OCC_VERSION_DEVELOPMENT AND OCC_VERSION_COMPLETE)
set (OCC_VERSION_STRING_EXT "${OCC_VERSION_COMPLETE}.${OCC_VERSION_DEVELOPMENT}" PARENT_SCOPE)
else()
set (OCC_VERSION_STRING_EXT "${OCC_VERSION_COMPLETE}" PARENT_SCOPE)
endif()
endfunction()
macro (CHECK_PATH_FOR_CONSISTENCY THE_ROOT_PATH_NAME THE_BEING_CHECKED_PATH_NAME THE_VAR_TYPE THE_MESSAGE_OF_BEING_CHECKED_PATH)

View File

@@ -25,7 +25,7 @@ foreach (OCCT_PACKAGE ${USED_PACKAGES})
set (HEADER_FILES)
# Generate Flex and Bison files
if (${REBUILD_PLATFORM_DEPENDENT_CODE})
if (${BUILD_YACCLEX})
# flex files
OCCT_ORIGIN_AND_PATCHED_FILES ("src/${OCCT_PACKAGE}" "*[.]lex" SOURCE_FILES_FLEX)
@@ -65,14 +65,14 @@ foreach (OCCT_PACKAGE ${USED_PACKAGES})
endif()
# header files
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/FILES")
file (STRINGS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/FILES" HEADER_FILES_M REGEX ".+[.]h")
file (STRINGS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/FILES" HEADER_FILES_LXX REGEX ".+[.]lxx")
file (STRINGS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/FILES" HEADER_FILES_GXX REGEX ".+[.]gxx")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/FILES")
file (STRINGS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/FILES" HEADER_FILES_M REGEX ".+[.]h")
file (STRINGS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/FILES" HEADER_FILES_LXX REGEX ".+[.]lxx")
file (STRINGS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/FILES" HEADER_FILES_GXX REGEX ".+[.]gxx")
file (STRINGS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/FILES" SOURCE_FILES_C REGEX ".+[.]c")
file (STRINGS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/FILES" SOURCE_FILES_C REGEX ".+[.]c")
if(APPLE)
file (STRINGS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/FILES" SOURCE_FILES_M REGEX ".+[.]mm")
file (STRINGS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/FILES" SOURCE_FILES_M REGEX ".+[.]mm")
endif()
else()
file (STRINGS "${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/FILES" HEADER_FILES_M REGEX ".+[.]h")
@@ -92,10 +92,10 @@ foreach (OCCT_PACKAGE ${USED_PACKAGES})
endif()
foreach(HEADER_FILE ${HEADER_FILES})
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
message (STATUS "Info. consider patched file: ${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
list (APPEND USED_INCFILES "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
SOURCE_GROUP ("Header Files\\${OCCT_PACKAGE}" FILES "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
message (STATUS "Info: consider patched file: ${BUILD_PATCH}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
list (APPEND USED_INCFILES "${BUILD_PATCH}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
SOURCE_GROUP ("Header Files\\${OCCT_PACKAGE}" FILES "${BUILD_PATCH}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
else()
list (APPEND USED_INCFILES "${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
SOURCE_GROUP ("Header Files\\${OCCT_PACKAGE}" FILES "${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/${HEADER_FILE}")
@@ -103,10 +103,10 @@ foreach (OCCT_PACKAGE ${USED_PACKAGES})
endforeach()
foreach(SOURCE_FILE ${SOURCE_FILES})
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
message (STATUS "Info. consider patched file: ${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
list (APPEND USED_SRCFILES "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
SOURCE_GROUP ("Source Files\\${OCCT_PACKAGE}" FILES "${APPLY_OCCT_PATCH_DIR}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
if (BUILD_PATCH AND EXISTS "${BUILD_PATCH}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
message (STATUS "Info: consider patched file: ${BUILD_PATCH}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
list (APPEND USED_SRCFILES "${BUILD_PATCH}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
SOURCE_GROUP ("Source Files\\${OCCT_PACKAGE}" FILES "${BUILD_PATCH}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
else()
list (APPEND USED_SRCFILES "${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
SOURCE_GROUP ("Source Files\\${OCCT_PACKAGE}" FILES "${CMAKE_SOURCE_DIR}/src/${OCCT_PACKAGE}/${SOURCE_FILE}")
@@ -116,41 +116,61 @@ foreach (OCCT_PACKAGE ${USED_PACKAGES})
endforeach()
string (REGEX REPLACE ";" " " PRECOMPILED_DEFS "${PRECOMPILED_DEFS}")
set (USED_RCFILE "")
if (MSVC)
set (USED_RCFILE "${CMAKE_BINARY_DIR}/resources/${PROJECT_NAME}.rc")
if (APPLY_OCCT_PATCH_DIR AND EXISTS "${APPLY_OCCT_PATCH_DIR}/adm/templates/occt_toolkit.rc.in")
configure_file("${APPLY_OCCT_PATCH_DIR}/adm/templates/occt_toolkit.rc.in" "${USED_RCFILE}" @ONLY)
else()
configure_file("${CMAKE_SOURCE_DIR}/adm/templates/occt_toolkit.rc.in" "${USED_RCFILE}" @ONLY)
endif()
endif()
if ("${PROJECT_NAME}" STREQUAL "DRAWEXE")
add_executable (${PROJECT_NAME} ${USED_SRCFILES} ${USED_INCFILES})
add_executable (${PROJECT_NAME} ${USED_SRCFILES} ${USED_INCFILES} ${USED_RCFILE})
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
else()
add_library (${PROJECT_NAME} ${USED_SRCFILES} ${USED_INCFILES})
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Release
RUNTIME DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin"
ARCHIVE DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
LIBRARY DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS RelWithDebInfo
RUNTIME DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini"
ARCHIVE DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
LIBRARY DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Debug
RUNTIME DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind"
ARCHIVE DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
LIBRARY DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd")
if (MSVC)
install (FILES ${CMAKE_BINARY_DIR}/${OS_WITH_BIT}/${COMPILER}/bind/${PROJECT_NAME}.pdb
if (DEFINED INSTALL_BIN_DIR)
install (TARGETS ${PROJECT_NAME} DESTINATION "${INSTALL_BIN_DIR}")
else()
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
else()
add_library (${PROJECT_NAME} ${USED_SRCFILES} ${USED_INCFILES} ${USED_RCFILE})
if (DEFINED INSTALL_LIB_DIR)
install (TARGETS ${PROJECT_NAME} DESTINATION "${INSTALL_LIB_DIR}")
else()
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Release
RUNTIME DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin"
ARCHIVE DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
LIBRARY DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS RelWithDebInfo
RUNTIME DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini"
ARCHIVE DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
LIBRARY DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi")
install (TARGETS ${PROJECT_NAME}
CONFIGURATIONS Debug
RUNTIME DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind"
ARCHIVE DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
LIBRARY DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd")
if (MSVC)
install (FILES ${CMAKE_BINARY_DIR}/${OS_WITH_BIT}/${COMPILER}/bind/${PROJECT_NAME}.pdb
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
endif()
endif()
set (CURRENT_MODULE)
@@ -162,10 +182,16 @@ foreach (OCCT_MODULE ${OCCT_MODULES})
endforeach()
if (CURRENT_MODULE)
set_property (TARGET ${PROJECT_NAME} PROPERTY FOLDER "Modules/${CURRENT_MODULE}")
set_target_properties (${PROJECT_NAME} PROPERTIES FOLDER "Modules/${CURRENT_MODULE}")
endif()
set_target_properties (${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "${PRECOMPILED_DEFS}")
get_property (OCC_VERSION_MAJOR GLOBAL PROPERTY OCC_VERSION_MAJOR)
get_property (OCC_VERSION_MINOR GLOBAL PROPERTY OCC_VERSION_MINOR)
get_property (OCC_VERSION_MAINTENANCE GLOBAL PROPERTY OCC_VERSION_MAINTENANCE)
set_target_properties (${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "${PRECOMPILED_DEFS}"
SOVERSION "${OCC_VERSION_MAJOR}"
VERSION "${OCC_VERSION_MAJOR}.${OCC_VERSION_MINOR}.${OCC_VERSION_MAINTENANCE}")
set (USED_TOOLKITS_BY_CURRENT_PROJECT)
set (USED_EXTERNAL_LIBS_BY_CURRENT_PROJECT)
@@ -173,19 +199,24 @@ set (USED_EXTERNAL_LIBS_BY_CURRENT_PROJECT)
# parce EXTERNLIB file
FILE_TO_LIST ("src/${PROJECT_NAME}/EXTERNLIB" USED_EXTERNLIB_AND_TOOLKITS)
foreach (USED_ITEM ${USED_EXTERNLIB_AND_TOOLKITS})
string (REGEX MATCH "^TK" TK_FOUND ${USED_ITEM})
if (NOT "${TK_FOUND}" STREQUAL "")
list (APPEND USED_TOOLKITS_BY_CURRENT_PROJECT ${USED_ITEM})
else()
string (REGEX MATCH "^CSF_" CSF_FOUND ${USED_ITEM})
if ("${CSF_FOUND}" STREQUAL "")
message (STATUS "Info: ${USED_ITEM} from ${PROJECT_NAME} skipped due to it is empty")
else() # get CSF_ value
set (CURRENT_CSF ${${USED_ITEM}})
if (NOT "${CURRENT_CSF}" STREQUAL "")
# prepare a list from a string with whitespaces
separate_arguments (CURRENT_CSF)
list (APPEND USED_EXTERNAL_LIBS_BY_CURRENT_PROJECT ${CURRENT_CSF})
string (REGEX MATCH "^ *#" COMMENT_FOUND ${USED_ITEM})
if (NOT COMMENT_FOUND)
string (REGEX MATCH "^TK" TK_FOUND ${USED_ITEM})
string (REGEX MATCH "^vtk" VTK_FOUND ${USED_ITEM})
if (NOT "${TK_FOUND}" STREQUAL "" OR NOT "${VTK_FOUND}" STREQUAL "")
list (APPEND USED_TOOLKITS_BY_CURRENT_PROJECT ${USED_ITEM})
else()
string (REGEX MATCH "^CSF_" CSF_FOUND ${USED_ITEM})
if ("${CSF_FOUND}" STREQUAL "")
message (STATUS "Info: ${USED_ITEM} from ${PROJECT_NAME} skipped due to it is empty")
else() # get CSF_ value
set (CURRENT_CSF ${${USED_ITEM}})
if (NOT "${CURRENT_CSF}" STREQUAL "")
# prepare a list from a string with whitespaces
separate_arguments (CURRENT_CSF)
list (APPEND USED_EXTERNAL_LIBS_BY_CURRENT_PROJECT ${CURRENT_CSF})
endif()
endif()
endif()
endif()
@@ -196,7 +227,7 @@ if (APPLE)
if (NOT ${IS_X11_FOUND} EQUAL -1)
find_package (X11 COMPONENTS X11 Xext Xmu Xi)
if (NOT X11_FOUND)
message (STATUS "Warning. X11 is not found. It's required to install The XQuartz project: http://www.xquartz.org")
message (STATUS "Warning: X11 is not found. It's required to install The XQuartz project: http://www.xquartz.org")
endif()
endif()
endif()

View File

@@ -236,30 +236,40 @@ macro (TBB_PRODUCT_SEARCH PRODUCT_NAME)
OCCT_MAKE_COMPILER_SHORT_NAME()
if (WIN32)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_DLL}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES ${3RDPARTY_${PRODUCT_NAME}_DLL}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES ${3RDPARTY_${PRODUCT_NAME}_DLL}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
if (DEFINED INSTALL_BIN_DIR)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_DLL} DESTINATION "${INSTALL_BIN_DIR}")
else()
install (FILES ${3RDPARTY_${PRODUCT_NAME}_DLL}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES ${3RDPARTY_${PRODUCT_NAME}_DLL}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES ${3RDPARTY_${PRODUCT_NAME}_DLL}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
else()
get_filename_component (PRODUCT_LIBRARY_NAME ${3RDPARTY_${PRODUCT_NAME}_LIBRARY} NAME)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_LIBRARY}.2
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${PRODUCT_LIBRARY_NAME}.2)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_LIBRARY}.2
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${PRODUCT_LIBRARY_NAME}.2)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_LIBRARY}.2
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${PRODUCT_LIBRARY_NAME}.2)
if (DEFINED INSTALL_LIB_DIR)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_LIBRARY}.2
DESTINATION "${INSTALL_LIB_DIR}"
RENAME ${PRODUCT_LIBRARY_NAME}.2)
else()
install (FILES ${3RDPARTY_${PRODUCT_NAME}_LIBRARY}.2
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib"
RENAME ${PRODUCT_LIBRARY_NAME}.2)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_LIBRARY}.2
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi"
RENAME ${PRODUCT_LIBRARY_NAME}.2)
install (FILES ${3RDPARTY_${PRODUCT_NAME}_LIBRARY}.2
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd"
RENAME ${PRODUCT_LIBRARY_NAME}.2)
endif()
endif()
endif()
mark_as_advanced (3RDPARTY_${PRODUCT_NAME}_LIBRARY 3RDPARTY_${PRODUCT_NAME}_DLL)

View File

@@ -203,32 +203,47 @@ if (INSTALL_TCL)
# collect and install all dlls from tcl dll dirs
file (GLOB TCL_DLLS "${3RDPARTY_TCL_DLL_DIR}/*.dll")
install (FILES ${TCL_DLLS}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES ${TCL_DLLS}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES ${TCL_DLLS}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
if (DEFINED INSTALL_BIN_DIR)
install (FILES ${TCL_DLLS} DESTINATION "${INSTALL_BIN_DIR}")
else()
install (FILES ${TCL_DLLS}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES ${TCL_DLLS}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES ${TCL_DLLS}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
else()
get_filename_component(3RDPARTY_TCL_LIBRARY_REALPATH ${3RDPARTY_TCL_LIBRARY} REALPATH)
install (FILES ${3RDPARTY_TCL_LIBRARY_REALPATH}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (FILES ${3RDPARTY_TCL_LIBRARY_REALPATH}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi")
install (FILES ${3RDPARTY_TCL_LIBRARY_REALPATH}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd")
if (DEFINED INSTALL_LIB_DIR)
install (FILES ${3RDPARTY_TCL_LIBRARY_REALPATH} DESTINATION "${INSTALL_LIB_DIR}")
else()
install (FILES ${3RDPARTY_TCL_LIBRARY_REALPATH}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (FILES ${3RDPARTY_TCL_LIBRARY_REALPATH}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi")
install (FILES ${3RDPARTY_TCL_LIBRARY_REALPATH}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd")
endif()
endif()
if (TCL_TCLSH_VERSION)
# tcl is required to install in lib folder (without)
install (DIRECTORY "${3RDPARTY_TCL_LIBRARY_DIR}/tcl8" DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (DIRECTORY "${3RDPARTY_TCL_LIBRARY_DIR}/tcl${TCL_TCLSH_VERSION}" DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
if (DEFINED INSTALL_LIB_DIR)
install (DIRECTORY "${3RDPARTY_TCL_LIBRARY_DIR}/tcl8" DESTINATION "${INSTALL_LIB_DIR}")
install (DIRECTORY "${3RDPARTY_TCL_LIBRARY_DIR}/tcl${TCL_TCLSH_VERSION}" DESTINATION "${INSTALL_LIB_DIR}")
else()
install (DIRECTORY "${3RDPARTY_TCL_LIBRARY_DIR}/tcl8" DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (DIRECTORY "${3RDPARTY_TCL_LIBRARY_DIR}/tcl${TCL_TCLSH_VERSION}" DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
endif()
else()
message (STATUS "\nWarning: tclX.X subdir won't be copyied during the installation process.")
message (STATUS "Try seeking tcl within another folder by changing 3RDPARTY_TCL_DIR variable.")
@@ -255,7 +270,7 @@ if (TK_FOUND AND 3RDPARTY_TCL_DIR)
if (${THE_SAME_FOLDER} EQUAL 0)
set (3RDPARTY_TCLTK_DIR "${3RDPARTY_TCL_DIR}")
message (STATUS "Info. TK is used from TCL folder: ${3RDPARTY_TCLTK_DIR}")
message (STATUS "Info: TK is used from TCL folder: ${3RDPARTY_TCLTK_DIR}")
endif()
endif()

View File

@@ -207,31 +207,45 @@ if (INSTALL_TK)
# collect and install all dlls from tk dll dirs
file (GLOB TK_DLLS "${3RDPARTY_TK_DLL_DIR}/*.dll")
install (FILES ${TK_DLLS}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES ${TK_DLLS}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES ${TK_DLLS}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
if (DEFINED INSTALL_BIN_DIR)
install (FILES ${TK_DLLS} DESTINATION "${INSTALL_BIN_DIR}")
else()
install (FILES ${TK_DLLS}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bin")
install (FILES ${TK_DLLS}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bini")
install (FILES ${TK_DLLS}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/bind")
endif()
else()
get_filename_component(3RDPARTY_TK_LIBRARY_REALPATH ${3RDPARTY_TK_LIBRARY} REALPATH)
install (FILES ${3RDPARTY_TK_LIBRARY_REALPATH}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (FILES ${3RDPARTY_TK_LIBRARY_REALPATH}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi")
install (FILES ${3RDPARTY_TK_LIBRARY_REALPATH}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd")
if (DEFINED INSTALL_LIB_DIR)
install (FILES ${3RDPARTY_TK_LIBRARY_REALPATH} DESTINATION "${INSTALL_LIB_DIR}")
else()
install (FILES ${3RDPARTY_TK_LIBRARY_REALPATH}
CONFIGURATIONS Release
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
install (FILES ${3RDPARTY_TK_LIBRARY_REALPATH}
CONFIGURATIONS RelWithDebInfo
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libi")
install (FILES ${3RDPARTY_TK_LIBRARY_REALPATH}
CONFIGURATIONS Debug
DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/libd")
endif()
endif()
if (TCL_TCLSH_VERSION)
# tk is required to install in lib folder (without)
install (DIRECTORY "${3RDPARTY_TK_LIBRARY_DIR}/tk${TCL_TCLSH_VERSION}" DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
if (DEFINED INSTALL_LIB_DIR)
install (DIRECTORY "${3RDPARTY_TK_LIBRARY_DIR}/tk${TCL_TCLSH_VERSION}" DESTINATION "${INSTALL_LIB_DIR}")
else()
install (DIRECTORY "${3RDPARTY_TK_LIBRARY_DIR}/tk${TCL_TCLSH_VERSION}" DESTINATION "${INSTALL_DIR}/${OS_WITH_BIT}/${COMPILER}/lib")
endif()
else()
message (STATUS "\nWarning: tkX.X subdir won't be copyied during the installation process.")
message (STATUS "Try seeking tk within another folder by changing 3RDPARTY_TK_DIR variable.")

View File

@@ -1,7 +1,7 @@
# variable description
#
set (APPLY_OCCT_PATCH_DIR_DESCR
set (BUILD_PATCH_DESCR
"Points to the directory recognized as a 'patch' for OCCT. If specified,
the files from this directory take precedence over the corresponding native
OCCT sources. This way you are able to introduce patches to Open CASCADE
@@ -13,19 +13,19 @@ set (BUILD_LIBRARY_TYPE_DESCR
are linked dynamically and loaded at runtime. 'Static' libraries
are archives of object files for use when linking other targets")
set (REBUILD_PLATFORM_DEPENDENT_CODE_DESCR
set (BUILD_YACCLEX_DESCR
"Enables Flex/Bison lexical analyzers. OCCT source files relating to STEP reader and
ExprIntrp functionality are generated automatically with Flex/Bison. Checking this options
leads to automatic search of Flex/Bison binaries and regeneration of the mentioned files")
set (OCCT_ALGO_EXTENDED_OUTPUT_DESCR
set (BUILD_WITH_DEBUG_DESCR
"Enables extended messages of many OCCT algorithms, usually printed to cout.
These include messages on internal errors and special cases encountered, timing etc")
# install variables
set (INSTALL_DIR_DESCR
"The place where built OCCT libraries, headers, test cases (INSTALL_OCCT_TEST_CASES variable),
samples (INSTALL_OCCT_SAMPLES_DESCR variable) and certain 3rdparties (INSTALL_GL2PS, INSTALL_TBB and
"The place where built OCCT libraries, headers, test cases (INSTALL_TEST_CASES variable),
samples (INSTALL_SAMPLES_DESCR variable) and certain 3rdparties (INSTALL_GL2PS, INSTALL_TBB and
other similar variables) will be placed during the installation process (building INSTALL project)")
macro (INSTALL_MESSAGE INSTALL_TARGET_VARIABLE INSTALL_TARGET_STRING)
@@ -34,8 +34,8 @@ set (${INSTALL_TARGET_VARIABLE}_DESCR
project) into the installation directory (INSTALL_DIR variable)")
endmacro()
INSTALL_MESSAGE (INSTALL_OCCT_SAMPLES "OCCT samples")
INSTALL_MESSAGE (INSTALL_OCCT_TEST_CASES "non-regression OCCT test scripts")
INSTALL_MESSAGE (INSTALL_SAMPLES "OCCT samples")
INSTALL_MESSAGE (INSTALL_TEST_CASES "non-regression OCCT test scripts")
INSTALL_MESSAGE (INSTALL_DOC_OcctOverview "OCCT overview documentation (HTML format)")
INSTALL_MESSAGE (INSTALL_FREEIMAGE "FreeImage binaries")
INSTALL_MESSAGE (INSTALL_FREEIMAGEPLUS "FreeImagePlus binaries")

View File

@@ -9,21 +9,6 @@ if (NOT DEFINED 3RDPARTY_VTK_DIR)
set (3RDPARTY_VTK_DIR "" CACHE PATH "The directory containing VTK")
endif()
set (3RDPARTY_VTK_REQUIRED_LIBRARIES vtkCommonCore
vtkCommonDataModel
vtkCommonExecutionModel
vtkCommonMath
vtkCommonTransforms
vtkRenderingCore
vtkRenderingFreeType
vtkRenderingFreeTypeOpenGL
vtkRenderingOpenGL
vtkFiltersGeneral
vtkIOCore
vtkIOImage
vtkImagingCore
vtkInteractionStyle)
# include occt macros. compiler_bitness, os_wiht_bit, compiler
OCCT_INCLUDE_CMAKE_FILE ("adm/cmake/occt_macros")
@@ -82,37 +67,33 @@ if (VTK_FOUND)
# add compiler flags, preprocessor definitions, include and link dirs
include (${VTK_USE_FILE})
set (ALL_REQUIRED_VTK_LIBRARIES_FOUND ON)
if (VTK_LIBRARIES)
set (3RDPARTY_VTK_INCLUDE_DIRS)
set (3RDPARTY_VTK_LIBRARY_DIRS)
set (3RDPARTY_VTK_DLL_DIRS)
foreach (VTK_REQUIRED_LIBRARY ${3RDPARTY_VTK_REQUIRED_LIBRARIES})
list (FIND VTK_LIBRARIES ${VTK_REQUIRED_LIBRARY} FOUND_INDEX)
if (${FOUND_INDEX} EQUAL -1)
message (WARNING "VTK: required ${VTK_REQUIRED_LIBRARY} library is not found")
set (ALL_REQUIRED_VTK_LIBRARIES_FOUND OFF)
else()
foreach (VTK_LIBRARY ${VTK_LIBRARIES})
string (REGEX MATCH "^vtk" IS_VTK_LIBRARY ${VTK_LIBRARY})
if (IS_VTK_LIBRARY)
# get paths from corresponding variables
if (${VTK_REQUIRED_LIBRARY}_INCLUDE_DIRS AND EXISTS "${${VTK_REQUIRED_LIBRARY}_INCLUDE_DIRS}")
list (APPEND 3RDPARTY_VTK_INCLUDE_DIRS "${${VTK_REQUIRED_LIBRARY}_INCLUDE_DIRS}")
if (${VTK_LIBRARY}_INCLUDE_DIRS AND EXISTS "${${VTK_LIBRARY}_INCLUDE_DIRS}")
list (APPEND 3RDPARTY_VTK_INCLUDE_DIRS "${${VTK_LIBRARY}_INCLUDE_DIRS}")
endif()
if (${VTK_REQUIRED_LIBRARY}_LIBRARY_DIRS AND EXISTS "${${VTK_REQUIRED_LIBRARY}_LIBRARY_DIRS}")
list (APPEND 3RDPARTY_VTK_LIBRARY_DIRS "${${VTK_REQUIRED_LIBRARY}_LIBRARY_DIRS}")
if (${VTK_LIBRARY}_LIBRARY_DIRS AND EXISTS "${${VTK_LIBRARY}_LIBRARY_DIRS}")
list (APPEND 3RDPARTY_VTK_LIBRARY_DIRS "${${VTK_LIBRARY}_LIBRARY_DIRS}")
endif()
if (${VTK_REQUIRED_LIBRARY}_RUNTIME_LIBRARY_DIRS AND EXISTS "${${VTK_REQUIRED_LIBRARY}_RUNTIME_LIBRARY_DIRS}")
list (APPEND 3RDPARTY_VTK_DLL_DIRS "${${VTK_REQUIRED_LIBRARY}_RUNTIME_LIBRARY_DIRS}")
if (${VTK_LIBRARY}_RUNTIME_LIBRARY_DIRS AND EXISTS "${${VTK_LIBRARY}_RUNTIME_LIBRARY_DIRS}")
list (APPEND 3RDPARTY_VTK_DLL_DIRS "${${VTK_LIBRARY}_RUNTIME_LIBRARY_DIRS}")
if (NOT WIN32)
list (APPEND 3RDPARTY_VTK_LIBRARY_DIRS "${${VTK_REQUIRED_LIBRARY}_RUNTIME_LIBRARY_DIRS}")
list (APPEND 3RDPARTY_VTK_LIBRARY_DIRS "${${VTK_LIBRARY}_RUNTIME_LIBRARY_DIRS}")
endif()
endif()
# get paths from corresponding properties
get_property (TARGET_VTK_IMPORT_CONFS TARGET ${VTK_REQUIRED_LIBRARY} PROPERTY IMPORTED_CONFIGURATIONS)
get_property (TARGET_VTK_IMPORT_CONFS TARGET ${VTK_LIBRARY} PROPERTY IMPORTED_CONFIGURATIONS)
if (TARGET_VTK_IMPORT_CONFS)
list (GET TARGET_VTK_IMPORT_CONFS 0 CHOSEN_IMPORT_CONF)
@@ -123,13 +104,13 @@ if (VTK_FOUND)
# endforeach()
#endif()
get_property (TARGET_PROPERTY_IMP_PATH TARGET ${VTK_REQUIRED_LIBRARY} PROPERTY IMPORTED_IMPLIB_${CHOSEN_IMPORT_CONF})
get_property (TARGET_PROPERTY_IMP_PATH TARGET ${VTK_LIBRARY} PROPERTY IMPORTED_IMPLIB_${CHOSEN_IMPORT_CONF})
if(TARGET_PROPERTY_IMP_PATH AND EXISTS "${TARGET_PROPERTY_IMP_PATH}")
get_filename_component (TARGET_PROPERTY_IMP_DIR "${TARGET_PROPERTY_IMP_PATH}" PATH)
list (APPEND 3RDPARTY_VTK_LIBRARY_DIRS "${TARGET_PROPERTY_IMP_DIR}")
endif()
get_property (TARGET_PROPERTY_LOCATION_PATH TARGET ${VTK_REQUIRED_LIBRARY} PROPERTY IMPORTED_LOCATION_${CHOSEN_IMPORT_CONF})
get_property (TARGET_PROPERTY_LOCATION_PATH TARGET ${VTK_LIBRARY} PROPERTY IMPORTED_LOCATION_${CHOSEN_IMPORT_CONF})
if(TARGET_PROPERTY_LOCATION_PATH AND EXISTS "${TARGET_PROPERTY_LOCATION_PATH}")
get_filename_component (TARGET_PROPERTY_LOCATION_DIR "${TARGET_PROPERTY_LOCATION_PATH}" PATH)
@@ -141,38 +122,32 @@ if (VTK_FOUND)
endif()
endif()
endif()
endforeach()
else()
set (ALL_REQUIRED_VTK_LIBRARIES_FOUND OFF)
endif()
if (ALL_REQUIRED_VTK_LIBRARIES_FOUND)
if (3RDPARTY_VTK_INCLUDE_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_VTK_INCLUDE_DIRS)
list (APPEND 3RDPARTY_INCLUDE_DIRS ${3RDPARTY_VTK_INCLUDE_DIRS})
if (3RDPARTY_VTK_INCLUDE_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_VTK_INCLUDE_DIRS)
list (APPEND 3RDPARTY_INCLUDE_DIRS ${3RDPARTY_VTK_INCLUDE_DIRS})
list (GET 3RDPARTY_VTK_INCLUDE_DIRS 0 3RDPARTY_VTK_INCLUDE_DIR)
set (3RDPARTY_VTK_INCLUDE_DIR "${3RDPARTY_VTK_INCLUDE_DIR}" CACHE PATH "The directory containing headers of VTK" FORCE)
endif()
list (GET 3RDPARTY_VTK_INCLUDE_DIRS 0 3RDPARTY_VTK_INCLUDE_DIR)
set (3RDPARTY_VTK_INCLUDE_DIR "${3RDPARTY_VTK_INCLUDE_DIR}" CACHE PATH "The directory containing headers of VTK" FORCE)
endif()
if (3RDPARTY_VTK_LIBRARY_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_VTK_LIBRARY_DIRS)
list (APPEND 3RDPARTY_LIBRARY_DIRS ${3RDPARTY_VTK_LIBRARY_DIRS})
if (3RDPARTY_VTK_LIBRARY_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_VTK_LIBRARY_DIRS)
list (APPEND 3RDPARTY_LIBRARY_DIRS ${3RDPARTY_VTK_LIBRARY_DIRS})
list (GET 3RDPARTY_VTK_LIBRARY_DIRS 0 3RDPARTY_VTK_LIBRARY_DIR)
set (3RDPARTY_VTK_LIBRARY_DIR "${3RDPARTY_VTK_LIBRARY_DIR}" CACHE PATH "The directory containing VTK libraries" FORCE)
endif()
list (GET 3RDPARTY_VTK_LIBRARY_DIRS 0 3RDPARTY_VTK_LIBRARY_DIR)
set (3RDPARTY_VTK_LIBRARY_DIR "${3RDPARTY_VTK_LIBRARY_DIR}" CACHE PATH "The directory containing VTK libraries" FORCE)
endif()
if (WIN32)
if (3RDPARTY_VTK_DLL_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_VTK_DLL_DIRS)
list (APPEND 3RDPARTY_DLL_DIRS ${3RDPARTY_VTK_DLL_DIRS})
if (WIN32)
if (3RDPARTY_VTK_DLL_DIRS)
list (REMOVE_DUPLICATES 3RDPARTY_VTK_DLL_DIRS)
list (APPEND 3RDPARTY_DLL_DIRS ${3RDPARTY_VTK_DLL_DIRS})
list (GET 3RDPARTY_VTK_DLL_DIRS 0 3RDPARTY_VTK_DLL_DIR)
set (3RDPARTY_VTK_DLL_DIR "${3RDPARTY_VTK_DLL_DIR}" CACHE PATH "The directory containing VTK shared libraries" FORCE)
endif()
list (GET 3RDPARTY_VTK_DLL_DIRS 0 3RDPARTY_VTK_DLL_DIR)
set (3RDPARTY_VTK_DLL_DIR "${3RDPARTY_VTK_DLL_DIR}" CACHE PATH "The directory containing VTK shared libraries" FORCE)
endif()
endif()
endif()
@@ -204,4 +179,6 @@ else()
set (USED_3RDPARTY_VTK_DIR ${3RDPARTY_VTK_LIBRARY_DIR})
endif()
mark_as_advanced (VTK_INCLUDE_DIRS VTK_LIBRARY_DIRS VTK_DIR)
OCCT_CHECK_AND_UNSET (VTK_INCLUDE_DIRS)
OCCT_CHECK_AND_UNSET (VTK_LIBRARY_DIRS)
OCCT_CHECK_AND_UNSET (VTK_DIR)

View File

@@ -731,7 +731,7 @@ proc OCCDoc_MakeDoxyfile {docType outDir tagFileDir {doxyFileName} {generatorMod
puts $doxyFile "DOTFILE_DIRS = $outDir/html"
puts $doxyFile "DOT_PATH = $graphvizPath"
puts $doxyFile "INCLUDE_PATH = [OCCDoc_GetIncDir $productsPath]"
puts $doxyFile "INCLUDE_PATH = [OCCDoc_GetSourceDir $productsPath]"
# list of files to generate
set mainpage [OCCDoc_MakeMainPage $outDir $outDir/$name.dox $modules $productsPath]

View File

@@ -1,7 +1,7 @@
#!/bin/bash
if [ "$COMPILER" == "@COMPILER@" ]; then
if [ "$ARCH" == "@COMPILER_BITNESS@" ]; then
if [ "$1" == "@COMPILER@" ]; then
if [ "$2" == "@COMPILER_BITNESS@" ]; then
export TCL_DIR="@USED_3RDPARTY_TCL_DIR@"
export TK_DIR="@USED_3RDPARTY_TK_DIR@"
export FREETYPE_DIR="@USED_3RDPARTY_FREETYPE_DIR@"
@@ -9,6 +9,32 @@ if [ "$COMPILER" == "@COMPILER@" ]; then
export GL2PS_DIR="@USED_3RDPARTY_GL2PS_DIR@"
export TBB_DIR="@USED_3RDPARTY_TBB_DIR@"
export VTK_DIR="@USED_3RDPARTY_VTK_DIR@"
export BIN_PATH="@INSTALL_BIN_DIR@"
if [ "$BIN_PATH" != "" ]; then
export PATH="${BIN_PATH}:${PATH}"
fi
export LIB_PATH="@INSTALL_LIB_DIR@"
if [ "$LIB_PATH" != "" ]; then
if [ "$LD_LIBRARY_PATH" != "" ]; then
export LD_LIBRARY_PATH="${LIB_PATH}:${LD_LIBRARY_PATH}"
else
export LD_LIBRARY_PATH="${LIB_PATH}"
fi
fi
export OCCT_RESOURCE_PATH="${CASROOT}/src"
if [ "@INSTALL_OCCT_RESOURCE_DIR@" != "" ]; then
export OCCT_RESOURCE_PATH="@INSTALL_OCCT_RESOURCE_DIR@"
fi
# required for set default testing environment
# and "Samples" window creation in DRAW
export OCCT_SHARE_PATH="${CASROOT}"
if [ "@INSTALL_SHARE_DIR@" != "" ]; then
export OCCT_SHARE_PATH="@INSTALL_SHARE_DIR@"
fi
fi
fi

View File

@@ -2,7 +2,7 @@
aScriptPath=${BASH_SOURCE%/*}; if [ -d "${aScriptPath}" ]; then cd "$aScriptPath"; fi; aScriptPath="$PWD";
source "${aScriptPath}/env.sh" "$1" "$2"
source "${aScriptPath}/env.sh" "$1"
echo 'Hint: use "pload ALL" command to load standard commands'
DRAWEXE

View File

@@ -5,7 +5,7 @@ set "SCRIPTROOT=%SCRIPTROOT:~0,-1%"
set "VCVER=@COMPILER@"
set "ARCH=@COMPILER_BITNESS@"
set "CASDEB=@BUILD_LETTER@"
set "CASDEB=@CURRENT_BUILD_LETTER@"
if not ["%1"] == [""] set "VCVER=%1"
if not ["%2"] == [""] set "ARCH=%2"

View File

@@ -35,7 +35,7 @@ fi
# ----- Set local settings -----
if [ -e "${aScriptPath}/custom.sh" ]; then
source "${aScriptPath}/custom.sh" "${COMPILER}" "${WOKSTATION}${ARCH}" "${CASDEB}"
source "${aScriptPath}/custom.sh" "${COMPILER}" "${ARCH}"
fi
THRDPARTY_PATH=""
@@ -76,15 +76,10 @@ if [ "$TK_DIR" != "$TCL_DIR" ]; then
fi
fi
BIN_PATH="${WOKSTATION}${ARCH}/${COMPILER}/bin${CASDEB}"
LIBS_PATH="${WOKSTATION}${ARCH}/${COMPILER}/lib${CASDEB}"
export PATH="${CASROOT}/${BIN_PATH}:${PATH}"
if [ "$LD_LIBRARY_PATH" != "" ]; then
export LD_LIBRARY_PATH="${CASROOT}/${LIBS_PATH}:${THRDPARTY_PATH}:${LD_LIBRARY_PATH}"
export LD_LIBRARY_PATH="${THRDPARTY_PATH}:${LD_LIBRARY_PATH}"
else
export LD_LIBRARY_PATH="${CASROOT}/${LIBS_PATH}:${THRDPARTY_PATH}"
export LD_LIBRARY_PATH="${THRDPARTY_PATH}"
fi
if [ "$WOKSTATION" == "mac" ]; then
@@ -99,34 +94,34 @@ fi
export CSF_LANGUAGE=us
export MMGT_CLEAR=1
export CSF_EXCEPTION_PROMPT=1
export CSF_SHMessage="${CASROOT}/src/SHMessage"
export CSF_MDTVTexturesDirectory="${CASROOT}/src/Textures"
export CSF_ShadersDirectory="${CASROOT}/src/Shaders"
export CSF_XSMessage="${CASROOT}/src/XSMessage"
export CSF_TObjMessage="${CASROOT}/src/TObj"
export CSF_StandardDefaults="${CASROOT}/src/StdResource"
export CSF_PluginDefaults="${CASROOT}/src/StdResource"
export CSF_XCAFDefaults="${CASROOT}/src/StdResource"
export CSF_TObjDefaults="${CASROOT}/src/StdResource"
export CSF_StandardLiteDefaults="${CASROOT}/src/StdResource"
export CSF_UnitsLexicon="${CASROOT}/src/UnitsAPI/Lexi_Expr.dat"
export CSF_UnitsDefinition="${CASROOT}/src/UnitsAPI/Units.dat"
export CSF_IGESDefaults="${CASROOT}/src/XSTEPResource"
export CSF_STEPDefaults="${CASROOT}/src/XSTEPResource"
export CSF_XmlOcafResource="${CASROOT}/src/XmlOcafResource"
export CSF_MIGRATION_TYPES="${CASROOT}/src/StdResource/MigrationSheet.txt"
export CSF_SHMessage="${OCCT_RESOURCE_PATH}/SHMessage"
export CSF_MDTVTexturesDirectory="${OCCT_RESOURCE_PATH}/Textures"
export CSF_ShadersDirectory="${OCCT_RESOURCE_PATH}/Shaders"
export CSF_XSMessage="${OCCT_RESOURCE_PATH}/XSMessage"
export CSF_TObjMessage="${OCCT_RESOURCE_PATH}/TObj"
export CSF_StandardDefaults="${OCCT_RESOURCE_PATH}/StdResource"
export CSF_PluginDefaults="${OCCT_RESOURCE_PATH}/StdResource"
export CSF_XCAFDefaults="${OCCT_RESOURCE_PATH}/StdResource"
export CSF_TObjDefaults="${OCCT_RESOURCE_PATH}/StdResource"
export CSF_StandardLiteDefaults="${OCCT_RESOURCE_PATH}/StdResource"
export CSF_UnitsLexicon="${OCCT_RESOURCE_PATH}/UnitsAPI/Lexi_Expr.dat"
export CSF_UnitsDefinition="${OCCT_RESOURCE_PATH}/UnitsAPI/Units.dat"
export CSF_IGESDefaults="${OCCT_RESOURCE_PATH}/XSTEPResource"
export CSF_STEPDefaults="${OCCT_RESOURCE_PATH}/XSTEPResource"
export CSF_XmlOcafResource="${OCCT_RESOURCE_PATH}/XmlOcafResource"
export CSF_MIGRATION_TYPES="${OCCT_RESOURCE_PATH}/StdResource/MigrationSheet.txt"
# Draw Harness special stuff
if [ -e "${CASROOT}/src/DrawResources" ]; then
export DRAWHOME="${CASROOT}/src/DrawResources"
export CSF_DrawPluginDefaults="${CASROOT}/src/DrawResources"
if [ -e "${OCCT_RESOURCE_PATH}/DrawResources" ]; then
export DRAWHOME="${OCCT_RESOURCE_PATH}/DrawResources"
export CSF_DrawPluginDefaults="${OCCT_RESOURCE_PATH}/DrawResources"
if [ -e "${CASROOT}/src/DrawResources/DrawDefault" ]; then
export DRAWDEFAULT="${CASROOT}/src/DrawResources/DrawDefault"
if [ -e "${OCCT_RESOURCE_PATH}/DrawResources/DrawDefault" ]; then
export DRAWDEFAULT="${OCCT_RESOURCE_PATH}/DrawResources/DrawDefault"
fi
fi
if [ -e "${CASROOT}/src/DrawResourcesProducts" ]; then
export CSF_DrawPluginProductsDefaults="${CASROOT}/src/DrawResourcesProducts"
if [ -e "${OCCT_RESOURCE_PATH}/DrawResourcesProducts" ]; then
export CSF_DrawPluginProductsDefaults="${OCCT_RESOURCE_PATH}/DrawResourcesProducts"
fi

View File

@@ -0,0 +1,30 @@
#include <windows.h>
#include <Standard_Version.hxx>
VS_VERSION_INFO VERSIONINFO
FILEVERSION OCC_VERSION_MAJOR, OCC_VERSION_MINOR, OCC_VERSION_MAINTENANCE, 0
PRODUCTVERSION OCC_VERSION_MAJOR, OCC_VERSION_MINOR, OCC_VERSION_MAINTENANCE, 0
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#ifdef _DEBUG
FILEFLAGS VS_FF_DEBUG
#endif
FILEOS VOS_NT
FILETYPE VFT_DLL
FILESUBTYPE VFT2_UNKNOWN
BEGIN
BLOCK "StringFileInfo"
BEGIN BLOCK "040904E4" // Language type = U.S English(0x0409) and Character Set = Windows, Multilingual(0x04E4)
BEGIN
VALUE "FileDescription", "@PROJECT_NAME@ Toolkit\000"
VALUE "FileVersion", OCC_VERSION_STRING_EXT "\000"
VALUE "LegalCopyright", "\251 OPEN CASCADE SAS\000"
VALUE "ProductName", "@PROJECT_NAME@\000"
VALUE "ProductVersion", OCC_VERSION_STRING_EXT "\000"
VALUE "OfficialSite", "www.opencascade.org\000"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x0409, 0x04E4
END
END

View File

@@ -502,7 +502,7 @@ proc DefineExplicitRtti {hxxfile class base theSourceExtensions} {
# try to find existing macro IMPLEMENT_STANDARD_RTTIEXT and check that
# it is consistent
foreach line $aFileContent {
if { [regexp {^\s*IMPLEMENT_STANDARD_RTTIEXT\s*\(\s*$class\s*,\s*([A-Za-z]+)\s*\)} $line res impl_base] } {
if { [regexp "^\\s*IMPLEMENT_STANDARD_RTTIEXT\\s*\\(\\s*$class\\s*,\\s*(\[A-Za-z0-9_\]+)\\s*\\)" $line res impl_base] } {
# implementation is in place, just report warning if second argument
# is different
if { $base != $impl_base } {
@@ -592,13 +592,14 @@ proc ConvertRtti {theProcessedPath theIncPaths theCheckMode theCompatibleMode \
# find all instances of DEFINE_STANDARD_RTTI with single or two arguments
set index 0
set pattern_rtti {^(\s*DEFINE_STANDARD_RTTI)\s*\(\s*([A-Za-z_0-9,\s]+)\s*\)}
set pattern_rtti {^(\s*DEFINE_STANDARD_RTTI)([_A-Z]+)?\s*\(\s*([A-Za-z_0-9,\s]+)\s*\)}
while { [regexp -start $index -indices -lineanchor $pattern_rtti \
$aProcessedFileContent location start clist] } {
$aProcessedFileContent location start suffix clist] } {
set index [lindex $location 1]
set start [eval string range \$aProcessedFileContent $start]
set clist [split [eval string range \$aProcessedFileContent $clist] ,]
set start [eval string range \$aProcessedFileContent $start]
set suffix [eval string range \$aProcessedFileContent $suffix]
set clist [split [eval string range \$aProcessedFileContent $clist] ,]
if { [llength $clist] == 1 } {
set class [string trim [lindex $clist 0]]
@@ -609,12 +610,8 @@ proc ConvertRtti {theProcessedPath theIncPaths theCheckMode theCompatibleMode \
logwarn "macro DEFINE_STANDARD_RTTI is changed assuming it inherits $inherits($class), please check!"
}
set change_flag 1
# try to inject macro IMPLEMENT_STANDARD_RTTIEXT in the
# corresponding source file (or check it already present),
# and depending on this, use either inline or out-of-line variant
set rtti_suffix [DefineExplicitRtti $aProcessedFile $class $inherits($class) $theSourceExtensions]
ReplaceSubString aProcessedFileContent $location \
"${start}${rtti_suffix}($class,$inherits($class))" index
"${start}EXT($class,$inherits($class))" index
}
} else {
logwarn "Error in $aProcessedFile: Macro DEFINE_STANDARD_RTTI used for class $class whose declaration is not found in this file, cannot fix"
@@ -624,14 +621,16 @@ proc ConvertRtti {theProcessedPath theIncPaths theCheckMode theCompatibleMode \
set base [string trim [lindex $clist 1]]
if { ! [info exists inherits($class)] } {
logwarn "Warning in $aProcessedFile: Macro DEFINE_STANDARD_RTTI used for class $class whose declaration is not found in this file"
} elseif { $base != $inherits($class) } {
} elseif { $base != $inherits($class) && ! [info exists inherits($class,multiple)] } {
logwarn "Warning in $aProcessedFile: Second argument in macro DEFINE_STANDARD_RTTI for class $class is $base while $class seems to inherit from $inherits($class)"
if { ! [info exists inherits($class,multiple)] } {
set base $inherits($class)
}
}
if { ! $theCheckMode } {
# convert intermediate version of macro DEFINE_STANDARD_RTTI
# with two arguments to either _INLINE or EXT variant
if { ! $theCheckMode && "$suffix" == "" } {
set change_flag 1
# try to inject macro IMPLEMENT_STANDARD_RTTIEXT in the
# corresponding source file (or check it already present),
# and depending on this, use either inline or out-of-line variant
set rtti_suffix [DefineExplicitRtti $aProcessedFile $class $base $theSourceExtensions]
ReplaceSubString aProcessedFileContent $location \
"${start}${rtti_suffix}($class,$base)" index
@@ -679,7 +678,7 @@ proc ConvertRtti {theProcessedPath theIncPaths theCheckMode theCompatibleMode \
# find all uses of macro STANDARD_TYPE and method DownCast and ensure that
# argument class is explicitly included
set pattern_incbeg {\s*#\s*include\s*[\"<]\s*}
set pattern_incbeg {\s*#\s*include\s*[\"<]\s*([A-Za-z0-9_/]*/)?}
set pattern_incend {[.][a-zA-Z]+\s*[\">]}
set index 0
set addtype {}
@@ -707,7 +706,9 @@ proc ConvertRtti {theProcessedPath theIncPaths theCheckMode theCompatibleMode \
if { ! $theCheckMode } {
set addinc ""
foreach type $addtype {
append addinc "\n#include <$type.hxx>"
if { "$aProcessedFileName" != "$type.hxx" } {
append addinc "\n#include <$type.hxx>"
}
}
if { [regexp -indices ".*\n${pattern_incbeg}\[A-Za-z0-9_/\]+${pattern_incend}" $aProcessedFileContent location] } {
set change_flag 1
@@ -734,6 +735,7 @@ proc ConvertHandle {theTargetPath theIncPaths theCheckMode theExtensions} {
# iterate by header files
foreach aHeader [glob -nocomplain -type f -directory $theTargetPath *.{$theExtensions}] {
set aCurrentHeaderName [file tail $aHeader]
# skip gxx files, as names Handle_xxx used there are in most cases
# placeholders of the argument types substituted by #define
@@ -767,8 +769,9 @@ proc ConvertHandle {theTargetPath theIncPaths theCheckMode theExtensions} {
set anUpdatedHeaderContent {}
set pattern_handle {\mHandle_([A-Za-z0-9_]+)}
foreach line $aHeaderContent {
# do not touch #include and #if... statements
if { [regexp {\s*\#\s*include} $line] || [regexp {\s*\#\s*if} $line] } {
# do not touch typedefs, #include, and #if... statements
if { [regexp {^\s*typedef} $line] ||
[regexp {^\s*\#\s*include} $line] || [regexp {^\s*\#\s*if} $line] } {
lappend anUpdatedHeaderContent $line
continue
}
@@ -848,8 +851,8 @@ proc ConvertHandle {theTargetPath theIncPaths theCheckMode theExtensions} {
} else {
# replace by forward declaration of a class or its include unless
# it is already declared or included
if { ! [regexp "^\s*\#\s*include\s*\[\<\"\]\s*$aForwardDeclHandledClass\s*\[\>\"\]" $aHeaderContent] } {
if { $isQObject } {
if { ! [regexp "\#\\s*include\\s*\[\<\"\]\\s*(\[A-Za-z0-9_/\]*/)?$aForwardDeclHandledClass\[.\]hxx\\s*\[\>\"\]" $aHeaderContent] } {
if { $isQObject && "$aCurrentHeaderName" != "${aForwardDeclHandledClass}.hxx" } {
lappend anUpdatedHeaderContent "#include <${aForwardDeclHandledClass}.hxx>"
if { ! [SearchForFile $theIncPaths ${aForwardDeclHandledClass}.hxx] } {
loginfo "Warning: include ${aForwardDeclHandledClass}.hxx added in $aHeader, assuming it exists and defines Handle_$aForwardDeclHandledClass"
@@ -1031,7 +1034,10 @@ proc ConvertCStyleHandleCast {pkpath theExtensions theCheckMode} {
while { [regexp -start $index -indices -lineanchor $pattern_refcast0 $hxx location class var] } {
set index [lindex $location 1]
logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
set var [eval string range \$hxx $var]
if { "$var" != "const" && "$var" != "Standard_OVERRIDE" } {
logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
}
}
# replace const Handle(A)& a = Handle(B)::DownCast (b); by

View File

@@ -0,0 +1,67 @@
// This is sample C++ file intended for testing and verifyig automatic upgrade
// script. Copy it with extension .cxx and apply upgrade procedure to see
// the result, as follows:
// > upgrade.bat -src=./adm -inc=./src -recurse -all
// Include of Geom_Line.hxx and Geom_Plane.hxx should be added below
#include <gp.hxx>
//========================================================================
// OCCT 7.0
//========================================================================
//------------------------------------------------------------------------
// Option -rtti
//------------------------------------------------------------------------
// Should be replaced by <Standard_Type.hxx>
#include <Standard_DefineHandle.hxx>
class A_0
{
}
class B_1 :
public A_0
{
// second argument "A_0" should be added
DEFINE_STANDARD_RTTI(B_1)
};
class C_2 : public Standard_Transient, B_1
{
// second argument "Standard_Transient" should be added
DEFINE_STANDARD_RTTI(C_2)
};
void for_rtti ()
{
Handle(Geom_Curve) aCurve = new Geom_Line (gp::Origin(), gp::DZ());
Handle(Geom_Line) aLine = Handle(Geom_Line)::DownCast (aCurve);
}
// should be removed
IMPLEMENT_DOWNCAST(A)
IMPLEMENT_STANDARD_RTTIEXT(A, B)
//------------------------------------------------------------------------
// Option -fwd
//------------------------------------------------------------------------
// force safe mode used for Qt objects
Q_OBJECT
slots:
// these includes should be recognized as corresponding to forward declarations
#include <occt/TColStd_HArray1OfReal.hxx>
// these declarations should be just removed
class Handle(TColStd_HArray1OfReal);
// should be replaced by include of corresponding header
class TColStd_Array1OfReal;
class Handle(Geom_Curve);
// check that trailing spaces at the following line are preserved
void ff();

View File

@@ -37,12 +37,10 @@ set (OCCT_CONFIG_FOR_DOXYGEN "${OCCT_GENERATED_DOC_DIR}/occt.cfg")
set (3RDPARTY_MATHJAX_RELATIVE_PATH "http://cdn.mathjax.org/mathjax/latest")
OCCT_VERSION (OCCT_SOURCE_VERSION)
configure_file ("${OCCT_OVERVIEW_RESOURCE_DIR}/occt_ug_html.doxyfile" "${OCCT_CONFIG_FOR_DOXYGEN}" COPYONLY)
# Add common options for generation of Overview and User Guides
file (APPEND ${OCCT_CONFIG_FOR_DOXYGEN} "\nPROJECT_NUMBER = ${OCCT_SOURCE_VERSION}")
file (APPEND ${OCCT_CONFIG_FOR_DOXYGEN} "\nPROJECT_NUMBER = ${OCC_VERSION_STRING_EXT}")
file (APPEND ${OCCT_CONFIG_FOR_DOXYGEN} "\nOUTPUT_DIRECTORY = ${OCCT_GENERATED_OVERVIEW_DIR}/.")
file (APPEND ${OCCT_CONFIG_FOR_DOXYGEN} "\nPROJECT_LOGO = ${OCCT_OVERVIEW_DIR}/resources/occ_logo.png")

View File

@@ -32,9 +32,6 @@ user_guides/ocaf/ocaf.md
user_guides/tobj/tobj.md
user_guides/draw_test_harness/draw_test_harness.md
user_guides/brep_wp/brep_wp.md
user_guides/ocaf_functionmechanism_wp/ocaf_functionmechanism_wp.md
user_guides/ocaf_tree_wp/ocaf_tree_wp.md
user_guides/ocaf_wp/ocaf_wp.md
user_guides/vis/vis.md
dev_guides/dev_guides.md

View File

@@ -12,9 +12,6 @@ user_guides/modeling_algos/modeling_algos.md
user_guides/boolean_operations/boolean_operations.md
user_guides/shape_healing/shape_healing.md
user_guides/ocaf/ocaf.md
user_guides/ocaf_functionmechanism_wp/ocaf_functionmechanism_wp.md
user_guides/ocaf_tree_wp/ocaf_tree_wp.md
user_guides/ocaf_wp/ocaf_wp.md
user_guides/step/step.md
user_guides/draw_test_harness/draw_test_harness.md
user_guides/tobj/tobj.md

View File

@@ -102,13 +102,15 @@ The following table enumerates the full list of environment variables used at co
| 3RDPARTY_GL2PS_* | Path | Path to GL2PS binaries |
| 3RDPARTY_TBB* | Path | Path to TBB binaries |
| 3RDPARTY_VTK_* | Path | Path to VTK binaries |
| BUILD_MODULE_<MODULE>| Boolean flag | Indicates whether the corresponding OCCT module should be built or not. It should be noted that some toolkits of a module can be built even if this module is not checked (this happens if some other modules depend on these toolkits). The main modules and their descriptions can be found in @ref occt_user_guides |
| BUILD_MODULE_<MODULE>| Boolean flag | Indicates whether the corresponding OCCT module should be built or not. It should be noted that some toolkits of a module can be built even if this module is not checked (this happens if some other modules depend on these toolkits). The main modules and their descriptions can be found in @ref user_guides |
| BUILD_LIBRARY_TYPE | String | Specifies the type of library to be created. "Shared" libraries are linked dynamically and loaded at runtime. "Static" libraries are archives of object files for use when linking other targets |
| BUILD_ADDITIONAL_TOOLKITS | String | Semicolon-separated individual toolkits to include into build process. If you want to build some particular libraries (toolkits) only, then you may uncheck all modules in the corresponding *BUILD_MODUE_\<MODULE\>* options and provide the list of necessary libraries here. Of course, all dependencies will be resolved automatically |
| REBUILD_PLATFORM_DEPENDENT_CODE | Boolean flag | Enables Flex/Bison lexical analyzers. OCCT source files relating to STEP reader and ExprIntrp functionality are generated automatically with Flex/Bison. Checking this options leads to automatic search of Flex/Bison binaries and regeneration of the mentioned files |
| BUILD_YACCLEX | Boolean flag | Enables Flex/Bison lexical analyzers. OCCT source files relating to STEP reader and ExprIntrp functionality are generated automatically with Flex/Bison. Checking this options leads to automatic search of Flex/Bison binaries and regeneration of the mentioned files |
| BUILD_MODULE_OcctMfcSamples | Boolean flag | Indicates whether MFC samples should be built together with OCCT. This option is only relevant to Windows platforms |
| BUILD_DOC_OcctOverview | Boolean flag | Indicates whether OCCT overview documentation project should be created together with OCCT. It is not built together with OCCT. Checking this options leads to automatic search of Doxygen binaries. Building of it will be call Doxygen command to generate the documentation in HTML format |
| APPLY_OCCT_PATH_DIR | Boolean flag | Points to the directory recognized as a "patch" for OCCT. If specified, the files from this directory take precedence over the corresponding native OCCT sources. This way you are able to introduce patches to Open CASCADE Technology not affecting the original source distribution |
| BUILD_PATCH | Path | Points to the directory recognized as a "patch" for OCCT. If specified, the files from this directory take precedence over the corresponding native OCCT sources. This way you are able to introduce patches to Open CASCADE Technology not affecting the original source distribution |
| BUILD_WITH_DEBUG | Boolean flag | Points to the directory recognized as a 'patch' for OCCT. If specified, the files from this directory take precedence over the corresponding native
OCCT sources. This way you are able to introduce patches to Open CASCADE Technology not affecting the original source distribution |
| CMAKE_CONFIGURATION_TYPES | String | Semicolon-separated CMake configurations |
| INSTALL_DIR | Path | Points to the installation directory |
| INSTALL_FREETYPE | Boolean flag | Indicates whether Freetype binaries should be installed into the installation directory |
@@ -117,8 +119,8 @@ The following table enumerates the full list of environment variables used at co
| INSTALL_TBB | Boolean flag | Indicates whether TBB binaries should be installed into the installation directory |
| INSTALL_VTK | Boolean flag | Indicates whether VTK binaries should be installed into the installation directory |
| INSTALL_TCL | Boolean flag | Indicates whether TCL binaries should be installed into the installation directory |
| INSTALL_OCCT_TEST_CASES | Boolean flag | Indicates whether non-regression OCCT test scripts should be installed into the installation directory |
| INSTALL_OCCT_SAMPLES | Boolean flag | Indicates whether OCCT samples should be installed into the installation directory |
| INSTALL_TEST_CASES | Boolean flag | Indicates whether non-regression OCCT test scripts should be installed into the installation directory |
| INSTALL_SAMPLES | Boolean flag | Indicates whether OCCT samples should be installed into the installation directory |
| INSTALL_DOC_OcctOverview | Boolean flag | Indicates whether OCCT overview documentation should be installed into the installation directory |
**Note:** In those CMake options defining paths only the forward slashes ("/") are acceptable.

View File

@@ -3,9 +3,9 @@ Using WOK {#occt_dev_guides__building_wok}
@tableofcontents
\ref occt_dev_guides__wok "WOK" is a legacy build environment for Open CASCADE Technology.
WOK is a legacy build environment for Open CASCADE Technology.
It is required for generation of header files for classes defined with
@ref occt_dev_guides__cdl "CDL" ("Cascade Definition Language").
CDL ("Cascade Definition Language").
Also tools for generation of project files for other build systems, and OCCT
documentation, are integrated to WOK.
@@ -105,7 +105,7 @@ and third-party components required for building OCCT.
Note that <i>$CASROOT</i> is equal to *D:/occt* now.
Then you can work with this workbench using normal WOK functionality (*wprocess, umake*, etc.; see @ref occt_dev_guides__wok "WOK User's Guide" for details) or use it only for generation of derived sources and project files, and build OCCT with Visual Studio on Windows or *make* command on Linux, as described below.
Then you can work with this workbench using normal WOK functionality (*wprocess, umake*, etc.) or use it only for generation of derived sources and project files, and build OCCT with Visual Studio on Windows or *make* command on Linux, as described below.
@section wok3 Generation of building projects

View File

@@ -486,7 +486,7 @@ They should be detailed enough to allow any person to understand what each part
It is recommended to comment all static functions (like methods in headers), and to insert at least one comment per each 10-100 lines in the function body.
There are also some rules that define how comments should be formatted, see <a href="#occt_coding_rules_3">Formatting Rules</a>.
There are also some rules that define how comments should be formatted, see @ref occt_coding_rules_3 "Formatting Rules".
Following these rules is important for good comprehension of the comments. Moreover, this approach allows automatically generating user-oriented documentation directly from the commented sources.

View File

@@ -2,282 +2,464 @@ Contribution Workflow {#occt_dev_guides__contribution_workflow}
====================================
@tableofcontents
@section occt_contribution_workflow_1 Introduction
@section occt_contribution_intro Introduction
The purpose of this document is to describe standard workflow for processing contributions to certified version of OCCT.
@subsection occt_contribution_workflow_1_1 Use of issue tracker system
@subsection occt_contribution_intro_tracker Use of issue tracker system
Each contribution should have corresponding issue (bug, or feature, or integration request)
registered in the MantisBT issue tracker system accessible by URL
http://tracker.dev.opencascade.org.
The issue is processed further according to the described workflow.
The issue is processed according to the described workflow.
@subsection occt_contribution_workflow_1_2 Access Levels
@subsection occt_contribution_intro_access Access levels
Access level defines the permissions of the user to view,
register and modify issues in a Mantis bugtracker.
The correspondence of access level and user permissions
is defined in accordance with the table below.
Access level defines the permissions of the user to view, register and modify issues in the issue tracker.
The correspondence of access level and user permissions is defined in the table below.
| Access level | Granted to | Permissions | Can set statuses |
|:------------- | :--------- | :-------------- | :----------------------- |
| Viewer | Everyone (anonymous access) | View public issues only | No |
| Reporter | Users registered on dev.opencascade.com | View, report, and comment issues | New, Resolved |
| Updater | Users of dev.opencascade.com in publicly visible projects | View and comment issues | New, Resolved |
| Developer | OCC developers and external contributors who signed the CLA | View, report, modify, and handle issues | New, Assigned, Resolved, Reviewed |
| Tester | OCC engineer devoted to certification testing | View, report, modify, and handle issues | Assigned, Tested |
| Manager | Person responsible for a project or OCCT component | View, report, modify, and handle issues | New, Resolved, Reviewed, Tested, Closed |
| Viewer | Everyone (anonymous access) | View public issues only | None |
| Updater | Users registered on dev.opencascade.org, in Open CASCADE project | View and comment issues | None |
| Reporter | Users registered on dev.opencascade.org, in Community project | View, report, and comment issues | New, Resolved, Feedback |
| Developer | OCC developers and (in Community project) external contributors who signed the CLA | View, report, modify, and handle issues | New, Assigned, Resolved, Reviewed, Feedback |
| Tester | OCC engineer devoted to certification testing | View, report, modify, and handle issues | Assigned, Tested, Feedback |
| Maintainer | Person responsible for a project or OCCT component | View, report, modify, and handle issues | New, Resolved, Reviewed, Tested, Closed, Feedback |
| Bugmaster | Person responsible for Mantis issue tracker, integrations, certification, and releases | Full access | All statuses |
According to his access level, the user can participate in the issue handling process under different roles, as described below.
@section occt_contribution_workflow_2 Typical workflow for an issue
@section occt_contribution_workflow Standard workflow for an issue
@subsection occt_contribution_workflow_2_1 General scheme
@subsection occt_contribution_workflow_general General scheme
@image html OCCT_ContributionWorkflow_V3_image001.png "Standard life cycle of an issue"
@image latex OCCT_ContributionWorkflow_V3_image001.png "Standard life cycle of an issue"
<center>
@image html OCCT_ContributionWorkflow_V3_image001.svg "Standard life cycle of an issue"
@image latex OCCT_ContributionWorkflow_V3_image001.svg "Standard life cycle of an issue"
</center>
@subsection occt_contribution_workflow_2_2 Issue registration
@subsection occt_contribution_workflow_issue Issue registration
An issue is registered in Mantis bugtracker by the Reporter with definition of the necessary attributes.
The definition of the following attributes is obligatory:
An issue is registered in Mantis bugtracker by the **Reporter** with definition of the necessary attributes (see also @ref occt_contribution_app):
* **Category** - indicates component of OCCT to which the issue relates. If in doubt, assign OCCT:Foundation Classes.
* **Reproducibility**
* **Severity**
* **Priority**
* **Profile** - allows defining the platform on which the problem was detected from the list of predefined platforms. If a platform is absent in the list of predefined platforms it is possible to use Or Fill In option to define the platform manually.
* **Platform**
* **OS**
* **OS Version**
* **Products Version** - defines the version of Open CASCADE on which the problem has been detected.
* **Summary** - a short, one sentence description of the issue. It has a limit of 128 characters. It should be informative and useful for the developers. It is advisable to avoid vague or misleading phrases, such as "it doesn't work" or "it crashed". It is not allowed to mention the issue originator, and in particular the customer, in the name of the registered issue.
* **Description** - should contain a detailed definition of the nature of the registered issue depending on its type. For a bug it is required to submit a detailed description of the incorrect behavior, including the indication of the cause of the problem (if possible at this stage) or any inputs from the originator. For a feature or integration request it is recommended to describe the proposed feature in details (as possible at that stage), including the changes required for its implementation and the main features of the new functionality. Filling the bug description is obligatory.
* **Steps To Reproduce** - in this field it is possible to describe in detail how to reproduce the issue. This field considerably helps to find the cause of the problem, to eliminate it and to create the test case.
* *Upload File* field allows attaching the shapes, scripts or modified source files of OCCT. It is recommended to attach a prototype test case in form of a Tcl script for DRAW, using either existing DRAW commands, or a C++ code which can be organized in DRAW commands, as well as sample shapes or other input data (if applicable), immediately after the issue registration.
**Category** -- indicates the OCCT component, to which the issue relates.
(If in doubt, assign to OCCT:Foundation Classes.)
**Severity** -- indicates the impact of the issue in the context where it was discovered.
**Profile** -- specifies the configuration, on which the problem was detected.
For specific configurations it is possible to specify separately platform, OS, and version.
These fields can be left empty if the issue is not configuration-specific.
Additional details relevant for the environment where the issue is reproduced (such as compiler version, bitness, etc.) can be provided in the **Description**.
**Products Version** -- defines the OCCT version, on which the problem has been detected.
It is preferable to indicate the version of the earliest known official release where the problem can be reproduced.
If the issue is reported on the current development version of OCCT, the current development version should be used (for convenience, this version is marked by asterisk in Mantis).
@note OCCT version number can be consulted in the file Standard_Version.hxx (value of OCC_VERSION_COMPLETE macro).
**Assign to** -- developer to whom the issue will be assigned.
By default, it is set to **Maintainer** of the OCCT component selected in **Category** field.
**Target Version** -- defines the target version for the fix to be provided.
By default, it is set to the current version under development.
**Summary** -- a short, one sentence description of the issue.
The newly registered issue gets status **NEW** and is assigned to the developer responsible for the OCCT component indicated in the Category field (Maintainer).
The **Summary** has a limit of 128 characters.
It should be informative and useful for the developers.
It is not allowed to mention the issue originator, and in particular the customer, in the name of the registered issue.
@subsection occt_contribution_workflow_2_3 Assigning the issue
A good practice is to start the issue with indication of the relevant component (OCCT module, package, class etc.) to better represent its context.
The description of the new issue is checked by the **Maintainer** and if it is feasible,
he may assign the issue to a **Developer**. Alternatively, any user with **Developer** access level
or higher can assign the issue to himself if he wants to provide a solution.
The summary should be given in imperative mood when it can be formulated as goal to be achieved or action to be done.
In particular, this applies to feature requests and improvements, for instance:
> *Visualization - provide a support of zoom persistent selection*
If the issue reports a problem, the summary should be given in Present Simple.
If reported problem is believed to be a regression, it is recommended to indicate this in the summary, like this:
> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data*
**Description** -- should contain a detailed definition of the nature of the registered issue depending on its type.
For a bug it is required to submit a detailed description of the incorrect behavior, including the indication of the cause of the problem (if known at this stage), and details on the context where the issue has been detected.
For a feature or integration request it is necessary to describe the proposed feature in details (as much as possible at that stage), including the changes required for its implementation and the main features of the new functionality.
Example:
> *Currently selection does not work correctly for non-zoomable objects (those defined using transform persistence). To provide correct selection for such objects, first-level (object) BVH structures must be updated on each camera change, and frustum must be rebuilt accordingly.*
@note In the description and notes to the issues you can refer to another issue by its ID prefixed by number sign (e.g.: #12345), and refer to a note by its ID prefixed by tilde (e.g.: ~20123).
These references will be expanded by Mantis into links to the corresponding issue or note.
When the number sign or the tilde followed by digits are a part of a normal text, add a space before digits (e.g.: "face # 12345 contains ~ 1000 edges") to avoid this conversion.
**Steps To Reproduce** -- allows describing in detail how to reproduce the issue.
This information is crucial for the developer to investigate the cause of the problem and to create the test case.
The optimal approach is to give a sequence of @ref occt_user_guides__test_harness "DRAW Test Harness" commands to reproduce the problem in DRAW.
This information can also be provided as a DRAW Tcl script attached to the issue (in **Upload File** field).
**Additional information and documentation updates** -- any additional information, remarks to be taken into account in Release Notes, etc..
**Upload File** -- allows attaching the shapes, snapshots, scripts, documents, or modified source files of OCCT.
This field can be used to attach a prototype test case in form of a Tcl script for DRAW, a C++ code which can be organized in DRAW commands, sample shapes, documents describing proposed change or analysis of the problem, or other data required for reproduction of the issue.
Where applicable, pictures demonstrating a problem and/or desired result can be attached.
The recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution.
The newly registered issue gets status **NEW** and is assigned to the person indicated in the **Assign to** field.
The **Maintainer, Technical Project Manager,** or **Bugmaster** can close or reassign the issue
(in **FEEDBACK** state) to the **Reporter** after it has been registered, if its description does not contain sufficient details to reproduce the bug or explain the purpose of the new feature.
That decision shall be documented in the comments to the issue in the Bugtracker.
@subsection occt_contribution_workflow_assign Assigning the issue
The assigned issue should have state **ASSIGNED**.
@subsection occt_contribution_workflow_2_4 Resolving the issue
The **Developer** responsible for the issue assigned to him provides a solution
as a change on the version of OCCT indicated in the issue attributes, or the last development version.
The modified sources should be submitted for review and testing to the dedicated branch of the official OCCT Git repository:
* Branch should be created for the issue with name composed of letters CR followed by issue ID number (without leading zeroes).
Optional suffix can be added to the branch name after issue ID,
e.g. to distinguish between several version of the fix.
* The branch should be based on recent version of the master branch
(not later than commit tagged as last OCCT release).
* The first line of the first commit message should contain
the Summary of the issue (starting with its ID followed by colon, e.g. "0022943: Bug TDataXtd_PatternStd").
The consequent lines should contain a description of the changes made.
If more than one commit has been made, the commit messages should contain description of the changes made.
* The amount of the code affected by the change should be limited
to only the changes required for the bug fix or improvement.
Change of layout or re-formatting of the existing code is allowed
only in the parts where meaningful changes related to the issue have been made.
* The name of the branch where the fix is submitted should be given
in the note to the Mantis issue
(providing the direct link to relevant branch view in GitWeb is encouraged).
* The description of the changes made should be put to the field
"Additional information and documentation updates" of the Mantis issue.
In some cases (if Git is not accessible for the contributor),
external contributions can be submitted as patch (diff) files or sources
attached to the Mantis issue, with indication of OCCT version on which the fix is made.
Such contributions should be put to Git for processing by someone else,
and hence they have less priority in processing than the ones submitted directly through Git.
The issue for which solution is provided should be switched to **RESOLVED** state
and assigned to the developer who is expected to make a code review
(the **Reviewer**; by default, can be set to the **Maintainer** of the component).
@subsection occt_contribution_workflow_2_5 Code review
The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT Code reviewing rules and examines all changes in the sources to detect obvious and possible errors, misprints, conformity to coding style.
The description of the new issue is checked by the **Maintainer** and if it is feasible, he may assign the issue to a **Developer**.
Alternatively, any user with **Developer** access level or higher can assign the issue to himself if he wants to provide a solution.
* If Reviewer detects some problems, he can either:
* Fix these issues and provide new solution, reassigning the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**.
Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developers forum if necessary).
* Reassign the issue back to the **Developer**, providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided.
* If Reviewer does not detect any problems, he changes status to **REVIEWED**.
The recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution.
@subsection occt_contribution_workflow_2_6 Testing
The **Maintainer** or **Bugmaster** can close or reassign the issue (in **FEEDBACK** state) to the **Reporter** after it has been registered, if its description does not contain sufficient details to reproduce the bug or explain the need of the new feature.
That decision shall be documented in the comments to the issue in the Bugtracker.
The assigned issue has status **ASSIGNED**.
@subsection occt_contribution_workflow_fix Resolving the issue
The **Developer** responsible for the issue assigned to him provides a solution including:
* Changes in the code, with appropriate comments;
* Test case (when applicable) and data necessary for its execution;
* Changes in the user and developer guides (when necessary).
The change is integrated to branch named CRxxxxx (where **xxxxx** is issue number) in the OCCT Git repository, based on current master, and containing a single commit with the appropriate description.
Then the issue is switched to **RESOLVED** for further review and testing.
The following sub-sections describe this process, relevant requirements and options, in more details.
@subsubsection occt_contribution_workflow_fix_code Requirements to the code modification
The amount of code affected by the change should be limited to the changes required for the bug fix or improvement.
Change of layout or re-formatting of the existing code is allowed only in the parts where meaningful changes related to the issue have been made.
@note If deemed useful, re-formatting or cosmetic changes affecting considerable parts of the code can be made within a dedicated issue.
The changes should comply with the OCCT @ref occt_dev_guides__coding_rules "Codng Rules".
It is especially important to comment the code properly so that other people can understand it easier.
The modification should be tested by running OCCT tests (on the platform and scope available to **Developer**) and ensuring absence of regressions.
In case if modification affects results of some existing test case and the new result is correct, such test case should be updated to report OK (or BAD), as descibed in @ref testmanual_details_results "Automated Test System / Interpretation of Test Results".
@subsubsection occt_contribution_workflow_fix_test Providing a test case
For modifications affecting OCCT functionality, a test case should be created (unless already exists) and included in the commit or patch.
See @ref testmanual_intro_quick_create "Automated Test System / Creating a New Test" for relevant instructions.
The data files required for a test case should be attached to the corresponding issue in Mantis (i.e. not included in the commit).
When the test case cannot be provided for any reason, the maximum possible information on how the problem can be reproduced and how to check the fix should be provided in the **Steps to Reproduce** field of an issue.
@subsubsection occt_contribution_workflow_fix_doc Updating user and developer guides
If the change affects a functionality described in @ref user_guides "User Guides", the corresponding user guide should be updated to reflect the change.
If the change affects OCCT test system, build environment, or development tools described in @ref dev_guides "Developer Guides", the corresponding guide should be updated.
The changes that break compatibility with the previous versions of OCCT (i.e. affecting API or behavior of existing functionality in the way that may require update of existing applications based on an earlier official release of OCCT to work correctly) should be described in the document @ref occt_dev_guides__upgrade "Upgrade from previous OCCT versions".
It is recommended to add a sub-section for each change described.
The description should provide the explanation of the incompatibility introduced by the change, and describe how it can be resolved (at least, in known situations).
When feasible, the automatic upgrade procedure (adm/upgrade.tcl) can be extended by a new option to perform the required upgrade of the dependent code automatically.
@subsubsection occt_contribution_workflow_fix_git Submission of change as a Git branch
The modification of sources should be provided in the dedicated branch of the official OCCT Git repository.
The branch should contain a single commit, with the appropriate commit message (see @ref occt_contribution_workflow_fix_commit "Requirements to the commit message" below).
In general, this branch should be based on the recent version of the master branch.
It is highly preferable to submit changes basing on the current master.
In case if the fix is implemented on the previous release of OCCT, the branch can be based on the corresponding tag in Git, instead of the master.
The branch name should be composed of letters **CR** (abbreviation of "Change Request") followed by the issue ID number (without leading zeros).
It is possible to add an optional suffix to the branch name after the issue ID, e.g. to distinguish between several versions of the fix (see @ref occt_contribution_nonstd_rebase).
See @ref occt_dev_guides__git_guide "Guide to using GIT" for help.
@note When a branch with the name given according to the above rule is pushed to Git, a note is automatically added to the corresponding issue in Mantis, indicating the person who has made the push, the commit hash, and (for new commits) the description.
@subsubsection occt_contribution_workflow_fix_commit Requirements to the commit message
The commit message posted in Git constitutes an integral part of both the fix and the release documentation.
The first line of the commit message should contain the Summary of the issue (starting with its ID followed by colon, e.g. "0022943: Bug in TDataXtd_PatternStd"), followed by an empty line.
The following lines should provide a description of the context and details on the changes made.
The contents and the recommended structure of the description depend on the nature of the bug.
In a general case, the following elements should be present:
* **Problem** a description of the unwanted behavior;
* **Change** a description of the implemented changes, including the names of involved classes / methods / enumerations etc.;
* **Result** a description of the current behavior (after the implementation).
Example:
> *0026330: BRepOffsetAPI_ThruSections creates invalid shape.*
>
> *Methods BRep_Tool::CurveOnSurface() and BRepCheck_Edge::InContext() now properly handle parametric range on a 3D curve when it is used to generate a p-curve dynamically (on a planar surface) and both the surface and the 3D curve have non-null locations.*
Provide sufficient context so that potential user of the affected functionality can understand what has been changed and how the algorithm works now.
Describe reason and essence of the changes made, but do not go too deep into implementation details -- these should be reflected in comments in the code.
@subsubsection occt_contribution_workflow_fix_resolve Marking issue as resolved
To mark the change as ready for review and testing, the corresponding issue should be switched to **RESOLVED** state.
By default, the issue gets assigned to the **Maintainer** of the component, who is thus responsible for its review.
Alternatively, another person can be selected as a reviewer at this step.
When the issue is switched to **RESOLVED**, it is required to update or fill the field **Steps to reproduce**.
The possible variants are:
* The name of an existing or new test case (preferred variant);
* A sequence of DRAW commands;
* N/A (Not required / Not possible / Not applicable);
* Reference to an issue in the bug tracker of another project.
@subsection occt_contribution_workflow_review Code review
The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT @ref occt_dev_guides__coding_rules "Coding Rules" and examines all changes in the sources, test case(s), and documentation to detect obvious and possible errors, misprints, or violations of the coding style.
If the Reviewer detects some problems, he can either:
* Fix these issues and provide a new solution.
The issue can then be switched to **REVIEWED**.
In case of doubt or possible disagreement the **Reviewer** can reassign the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**.
Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developers forum if necessary).
* Reassign the issue back to the **Developer**, providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided.
If Reviewer does not detect any problems, or provides a corrected version, he changes status to **REVIEWED**.
The issue gets assigned to the **Bugmaster**.
@subsection occt_contribution_workflow_test Testing
The issues that are in **REVIEWED** state are subject of certification (non-regression) testing.
The issue is assigned to OCC **Tester** when he starts processing it.
The results of tests are checked by the **Tester**:
* If the **Tester** detects build problems or regressions, he changes the status to **ASSIGNED** and reassigns the issue to the **Developer** with a detailed description of the problem. The **Developer** should produce a new solution.
* If the **Tester** does not detect build problems or regressions, he changes the status to **TESTED** for further integration.
The issue is assigned to an OCCT **Tester** when he starts processing it.
@subsection occt_contribution_workflow_2_7 Integration of a solution
If the branch submitted for testing is based on obsolete status of the master branch, **Tester** @ref occt_contribution_nonstd_rebase "rebases" it on master HEAD.
In case of conflicts, the issue is assigned back to **Developer** in **FEEDBACK** status, requesting for a rebase.
Before integration into the master branch of the repository the **Integrator** checks the following conditions:
Certification testing includes:
* Addition of new data models (if required for a new test case) to the data base;
* Revision of the new test case(s) added by developer, and changes in the existing test cases included in commit.
The **Tester** can amend tests to ensure their correct behavior in the certification environment.
* Building OCCT on a sub-set of supported configurations (OS and compiler), watching for errors and warnings;
* Execution of tests on sub-set of supported platforms (at least, one Windows and one Linux configuration), watching for regressions;
* Building OCCT samples, watching for errors;
* Building and testing of OCC products based on OCCT.
If the **Tester** does not detect problems or regressions, he changes the status to **TESTED** for further integration.
If the **Tester** detects build problems or regressions, he changes the status to **ASSIGNED** and reassigns the issue to the **Developer** with a detailed description of the problems.
The **Developer** should analyze the reported problems and, depending on results of this analysis, either:
* Confirm that the detected problems are expected changes and they should be accepted as a new status of the code. Then the issue should be switched to **FEEDBACK** and assigned to the **Bugmaster**.
* Produce a new solution (see @ref occt_contribution_workflow_fix, and also @ref occt_contribution_nonstd_minor).
@subsection occt_contribution_workflow_integrate Integration of a solution
Before integration into the master branch of the repository the **Integrator** checks the following conditions:
* the change has been reviewed;
* the change has been tested without regressions (or with regressions treated properly);
* the test case has been created for this issue (when applicable), and the change has been rechecked on this test case;
* "Additional information and documentation updates" field is filled by the developer;
* the change does not conflict with other changes integrated previously.
If the result of check is successful the Integrator integrates solution
into the master branch of the repository. Each change is integrated into the master branch
as a single commit without preserving the history of changes made in the branch
(by rebase, squashing all intermediate commits), however, preserving the author when possible.
This is done to have the master branch history plain and clean.
The following picture illustrates the process:
If the result of check is successful the Integrator integrates the solution into the branch.
The integrations are performed weekly; integration branches are named following the pattern IR-YYYY-MM-DD.
Each change is integrated as a single commit without preserving the history of changes made in the branch (by rebase, squashing all intermediate commits if any), however, preserving the author when possible.
This is done to have the master branch history plain and clean.
The following picture illustrates the process:
@image html OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches"
@image latex OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches"
@image html OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches" width=\textwidth
@image latex OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches" width=\textwidth
The new master branch is tested against possible regressions that might appear due to interference between separate changes. When the tests are Ok, the new master is pushed to the official repository
and the original branches are removed from it.
The issue status is set then to **VERIFIED** and is assigned to the **Reporter** so that he could check the fix as-integrated.
The new integration branch is tested against possible regressions that might appear due to interference between separate changes.
When the tests are OK, the integration branch is pushed as the new master to the official repository.
The issue status is set then to **VERIFIED** and is assigned to the **Reporter** so that he could check the fix as integrated.
@subsection occt_contribution_workflow_2_8 Closing a bug
The branches corresponding to the integrated fixes are removed from the repository by the **Bugmaster**.
The **Bugmaster** closes the issue after regular OCCT Release provided that the issue status is **VERIFIED** and that issue was really solved in that release, by rechecking the corresponding test case. The final issue state is **CLOSED**.
@subsection occt_contribution_workflow_close Closing an issue
@subsection occt_contribution_workflow_2_9 Reopening a bug
When possible, the **Reporter** should check whether the problem is actually resolved in the environment where it has been discovered, after the fix is integrated to master.
If the fix does not actually resolve the original problem, the issue in **VERIFIED** status can be reopened and assigned back to the **Developer** for rework.
The details on how to check that the issue is still reproducible should be provided.
However, if the issue does resolve the problem as described in the original report, but a similar problem is discovered for another input data or configuration, or the fix has caused a regression, that problem should be registered as a separate (@ref occt_contribution_nonstd_relate "related") issue.
If a regression is detected, the **Bugmaster** may reopen and reassign the **CLOSED** issue to the appropriate developer with comprehensive comments about the reason of reopening. The issue then becomes **ASSIGNED** again.
If the fix integrated to master causes regressions, **Bugmaster** can revert it and reopen the issue.
@section occt_contribution_workflow_3 Appendix
The **Bugmaster** closes the issue after the regular OCCT Release, provided that the issue status is **VERIFIED** and the change was actually included in the release.
The final issue state is **CLOSED**.
@subsection occt_contribution_workflow_3_1 Issue attributes
The field **Fixed in Version** of the issue is set to the OCCT version where it is fixed.
@subsubsection occt_contribution_workflow_3_1_1 Severity
@section occt_contribution_nonstd Additional workflow elements
@subsection occt_contribution_nonstd_feedback Requesting more information or specific action
If, at any step of the issue lifetime, the person responsible for it cannot process it due to absence of required information, expertise, or rights, he can switch it to status **FEEDBACK** and assign to the person who is (presumably) able to resolve the block. Some examples of typical situations where **FEEDBACK** is used are:
* The **Maintainer** or the **Developer** requests for more information from the **Reporter** to reproduce the issue;
* The **Tester** requests the **Developer** or the **Maintainer** to help him in the interpretation of testing results;
* The **Developer** or the **Maintainer** asks the **Bugmaster** to close the issue that is found irrelevant or already fixed (see @ref occt_contribution_nonstd_autofix).
In general, issues with status **FEEDBACK** should be processed as fast as possible, to avoid unjustified delays.
@subsection occt_contribution_nonstd_relate Defining relationships between issues
When two or more issues are related to each other, this relationship should be reflected in the issue tracker.
It is also highly recommended to add a note to explain the relationship.
Typical cases of relationships are:
* Issue A is caused by previous fix made for issue B (A is a child of B);
* Issue A describes the same problem as issue B (A is a duplicate of B);
* Issues A and B relate to the same piece of code, functionality etc., in the sense that the fix for one of these issues will affect the other (A is related to B)
When the fix made for one issue also resolves another one, these issues should be marked as related or duplicate.
In general, the duplicate issue should have the same status, and, when closed, be marked as fixed in the same OCCT version, as the main one.
@subsection occt_contribution_nonstd_patch Submission of a change as a patch
In some cases (if Git is not accessible for the contributor), external contributions can be submitted as a patch file (generated by *diff* command) or as modified sources attached to the Mantis issue.
The OCCT version, for which the patch is generated, should be clearly specified (e.g. as hash code of Git commit if the patch is based on an intermediate state of the master).
@note Such contributions should be put to Git by someone else (e.g. the **Reviewer**), this may cause delay in their processing.
@subsection occt_contribution_nonstd_rebase Updating branches in Git
Updates of the existing branch (e.g. taking into account the remarks of the **Reviewer**, or fixing regressions) should be provided as new commits on top of previous state of the branch.
It is allowed to rebase the branch on the new state of the master and push it to the repository under the same name (with <i>--force</i> option) provided that the original sequence of commits is preserved.
When a change is squashed into a single commit (e.g. to be submitted for review), it should be pushed into a branch a with different name.
The recommended approach is to add a numeric suffix (index) indicating the version of the change, e.g. "CR12345_5".
Usually it is worth keeping a non-squashed branch in Git for reference.
To avoid confusions, the branch corresponding to the latest version of the change should have a greater index.
@note Make sure to revise the commit message after squashing a branch, to keep it meaningful and comprehensive.
@subsection occt_contribution_nonstd_minor Minor corrections
In some cases review remarks or results of testing require only minor corrections to be done in the branch containing a change.
"Minor" implies that the correction does not impact the functionality and does not affect the description of the previously committed change.
As an exception to general @ref occt_contribution_workflow_fix_git "single-commit rule", it is allowed to put such minor corrections on top of the existing branch as a separate commit, and re-submit it for further processing in the same branch, without squashing.
Minor commits should have a single-line message starting with //.
These messages will be ignored when the branch is squashed at integration.
Typical cases of minor corrections are:
* Amendments of test cases (including those made by the **Tester** to adjust a test script to a specific platform);
* Trivial corrections of compilation warnings (such as removal of an unused variable);
* Addition or correction of comments or documentation;
* Corrections of code formatting (e.g. reversion of irrelevant formatting changes made in the main commit).
@subsection occt_contribution_nonstd_autofix Handling non-reproducible issues
Investigation of each issue starts with reproducing it on current development version (master).
If it cannot be reproduced on the current master, but can be reproduced on one of previous releases (or previous state of the master), it is considered as solved by a change made for another issue.
If that "fixing" issue can be identified (e.g. by parsing Git log), it should be set as related to that issue.
The issue should be switched to **FEEDBACK** and assigned to the **Bugmaster** for further processing.
The **Bugmaster** decides whether it is necessary to create a test case for that issue, and if so may assign it to the **Developer** or the **Tester** to create a test.
The issue then follows the standard workflow.
Otherwise, if the issue is fixed in one of previous releases, the **Bugmaster** closes it setting the appropriate value in **Fixed in Version** field, or, if the issue is fixed after the last release, switches it to **VERIFIED** status.
If the issue cannot be reproduced due to an unclear description, missing data, etc., it should be assigned back to the **Reporter** in **FEEDBACK** status, requesting for more information.
The **Reporter** should provide additional information within one month; after that time, if no new information is provided, the issue should be closed by the **Bugmaster** with resolution **Unable to reproduce**.
@section occt_contribution_app Appendix: Issue attributes
@subsection occt_contribution_app_category Category
The category corresponds to the component of OCCT where the issue is found:
| Category | Component |
| :--------------------------- | :----------------------------------------------------- |
| OCCT:Foundation Classes | Foundation Classes module |
| OCCT:Modeling Data | Modeling Data classes |
| OCCT:Modeling Algorithms | Modeling Algorithms, except shape healing and meshing |
| OCCT:Shape Healing | Shape Healing component (TKShapeHealing) |
| OCCT:Mesh | BRepMesh algorithm |
| OCCT:Data Exchange | Data Exchange module |
| OCCT:Visualization | Visualization module |
| OCCT:Application Framework | OCAF |
| OCCT:DRAW | DRAW Test Harness |
| OCCT:Tests | Automatic Test System |
| OCCT:Documentation | Documentation |
| OCCT:Coding | General code quality |
| OCCT:Configuration | Configuration, build system, etc. |
| OCCT:Releases | Official OCCT releases |
| Website:Tracker | OCCT Mantis issue tracker, tracker.dev.opencascade.org |
| Website:Portal | OCCT development portal, dev.opencascade.org |
| Website:Git | OCCT Git repository, git.dev.opencascade.org |
@subsection occt_contribution_app_severity Severity
Severity shows at which extent the issue affects the product.
The list of used severities is given in the table below in the descending order.
| Severity | Description | Weight for Bug Score |
| :---------- | :------------------------------------------------ | :------------------: |
| crash | Crash of the application or OS, loss of data | 5 |
| block | Regression corresponding to the previously delivered official version. Impossible operation of a function on any data with no work-around. Missing function previously requested in software requirements specification. Destroyed data. | 4 |
| major | Impossible operation of a function with existing work-around. Incorrect operation of a function on a particular dataset. Impossible operation of a function after intentional input of incorrect data. Incorrect behavior of a function after intentional input of incorrect data. | 3 |
| minor | Incorrect behavior of a function corresponding to the description in software requirements specification. Insufficient performance of a function. | 2 |
| tweak | Ergonomic inconvenience, need of light updates. | 1 |
| text | Inconsistence of program code to the Coding Standard. Errors in source text (e.g. unnecessary variable declarations, missing comments, grammatical errors in user manuals). | 1 |
| trivial | Cosmetic bugs. | 1 |
| feature | Bug fix, new feature, improvement that requires workload estimation and validation. | 1 |
| integration request | Requested integration of an existing feature into the product. | 0 |
| Just a question | A question to be processed, without need of any changes in the product. | 0 |
| Severity | Description |
| :---------- | :------------------------------------------------ |
| crash | Crash of the application or OS, loss of data |
| block | Regression corresponding to the previously delivered official version. Impossible operation of a function on any data with no work-around. Missing function previously requested in software requirements specification. Destroyed data. |
| major | Impossible operation of a function with existing work-around. Incorrect operation of a function on a particular dataset. Impossible operation of a function after intentional input of incorrect data. Incorrect behavior of a function after intentional input of incorrect data. |
| minor | Incorrect behavior of a function corresponding to the description in software requirements specification. Insufficient performance of a function. |
| tweak | Ergonomic inconvenience, need of light updates. |
| text | Non-conformance of the program code to the Coding Rules, mistakes and non-functional errors in the source text (e.g. unnecessary variable declarations, missing comments, grammatical errors in user manuals). |
| trivial | Cosmetic issues. |
| feature | Request for a new feature or improvement. |
| integration request | Requested integration of an existing feature into the product. |
| just a question | A question to be processed, without need of any changes in the product. |
@subsubsection occt_contribution_workflow_3_1_2 Statuses of issues
@subsection occt_contribution_app_status Status
The bug statuses that can be applied to the issues are listed in the table below.
| Status | Description |
| :------------------- | :----------------------------------------- |
| New | New just registered issue. Testing case should be created by Reporter. |
| Feedback | The issue requires more information; the original posters should pay attention. |
| New | A new, just registered issue. |
| Acknowledged | Can be used to mark the issue as postponed. |
| Confirmed | Can be used to mark the issue as postponed. |
| Feedback | The issue requires more information or a specific action. |
| Assigned | Assigned to a developer. |
| Resolved + a resolution | The issue has been fixed, and now is waiting for revision. |
|Revised + a resolution | The issue has been revised, and now is waiting for testing. |
| Resolved | The issue has been fixed, and now is waiting for review. |
| Reviewed | The issue has been reviewed, and now is waiting for testing (or being tested). |
| Tested | The fix has been internally tested by the tester with success on the full non-regression database or its part and a test case has been created for this issue. |
| Verified | The fix has been integrated into the master of the corresponding repository |
| Closed | The fix has been integrated to the master. The corresponding test case has been executed successfully. The issue is no longer reproduced. |
| Closed + resolution | The fix has been integrated to the master. The corresponding test case has been executed successfully. The issue is no longer reproduced. |
@subsubsection occt_contribution_workflow_3_1_3 Resolutions
@subsection occt_contribution_app_resolution Resolution
**Resolution** is set when the bug is resolved. "Reopen" resolution is added automatically when the bug is reopened.
**Resolution** is set when the bug is closed. "Reopen" resolution is added automatically when the bug is reopened.
| Resolution | Description |
|:--------------------- | :--------------------------------------------------------------------------- |
| Open | The issue is being processed. |
| Open | The issue is pending. |
| Fixed | The issue has been successfully fixed. |
| Reopened | The bug has been reopened because of insufficient fix or regression. |
| Unable to reproduce | The bug is not reproduced. |
| Not fixable | The bug cannot be fixed because it is a bug of third party software, or because it requires more workload than it can be allowed. |
| Unable to reproduce | The bug is not reproduced. |
| Not fixable | The bug cannot be fixed because e.g. it is a bug of third party software, OS or hardware limitation, etc. |
| Duplicate | The bug for the same issue already exists in the tracker. |
| Not a bug | It is a normal behavior in accordance with the specification of the product |
| No change required | The issue didnt require any change of the product, such as a question issue |
| Suspended | This resolution is set for Acknowledged status only. It means that the issue is waiting for fix until a special administrative decision is taken (e.g. a budget is not yet set in accordance with the contract) |
| Documentation updated | The issue was a normal behavior of the product, but the actions of the user were wrong. The specification and the user manual have been updated to reflect this issue. |
| Wont fix | An administrative/contractual decision has been taken to not fix the bug |
@subsection occt_contribution_workflow_3_2 Update and evolution of documentation
The documentation on Open CASCADE Technology currently exists in three forms:
* OCCT Technical Documentation generated automatically with Doxygen tool on the basis of comments in CDL or HXX files.
* Users Reference Documentation on OCCT packages and Products supplied in the form of PDF Users guides
* OCCT Release Documentation supplied in the form of Release Notes with each release.
It is strictly required to properly report the improvements and changes introduced in OCCT in all three forms of Documentation.
@subsubsection occt_contribution_workflow_3_2_1 Maintenance of CDL files
Every developer providing a contribution to the source code of OCC
should make a relevant change in the corresponding header file, including CDL.
Making the appropriate comments is mandatory in the following cases:
* Development of a new package / class / method / enumeration;
* Modification of an existing package / class / method / enumeration that changes its behavior;
* Modification / new development impacts at other packages / classes / methods / enumerations, the documentation which of should be modified correspondingly.
The only case when the comments may be not required is introducing
a modification that does not change the existing behavior in any noticeable way
or brings the behavior in accordance with the existing description.
CDL description must be in good English, containing as much relevant
information and as clear as possible. If the developer is unable to properly formulate
his ideas in English or suspects that his description can be misunderstood,
he should address to the Documentation Engineer for language assistance.
Such action is completely subject to the discretion of the developer; however,
the Documentation Engineer can require that the developer should provide a relevant
technical documentation and reopen a bug until all documentation satisfies the requirements above.
@subsubsection occt_contribution_workflow_3_2_2 Maintenance of the Users Reference Documentation
The Users Reference Documentation is distributed among a number of Users Guides,
each describing a certain module of OCCT.
The User's Guides do not cover the entire functionality of OCCT;
however, they describe most widely used and important packages.
In most aspects the User's Guides present the information that is contained in CDL descriptions for methods, classes, etc., only from a different point of view. Thus, it is required that any developer who implements a new or modifies an existing package / class / method / enumeration and adds a description of new development or changes in the corresponding CDL file should also check if this class package / class / method / enumeration or the package / class, to which the added class / method belongs is already described in the documentation and update the Users Reference Documentation correspondingly.
3.2.3. Preparation of the Release Documentation
Before changing the bug Status to RESOLVED, the developer should provide a description of the implemented work using the "Additional information and documentation updates" field of Mantis bugtracker.
This description is used for the Release Documentation and has the following purposes:
* to inform the OCCT users about the main features and improvements implemented in the platform in the release;
* to give a complete and useable list of changes introduced into the OCCT since the latest version.
The changes should be described from the users viewpoint so that the text
could be comprehensible even for beginners having a very vague idea about OCCT.
If the developer is unable to properly formulate his ideas in English or suspects
that his description can be misunderstood, he should address to the Documentation Engineer
for language assistance. Such action is completely subject to the discretion of the developer;
however, the Documentation Engineer can require that the developer
should provide a relevant technical documentation and reopen a bug
until all documentation satisfies the requirements.
**Note**, that it is required to single out the changes in the OCCT behavior as compared to the previous versions and especially the changes to be considered when porting from the previous version of OCCT.
For example:
* If global macros XXX() was used in the code of your application, revise it for direct use of the argument stream object.
* You might need to revise the code related to text display in 3d viewer to take into account new approach of using system fonts via XXX library.
The **Documentation Engineer** is responsible for preparation of the version Release Notes
and update of the Users Guides. If the **Documentation Engineer** considers that the description currently provided by the **Developer** is somehow inadequate or unsatisfactory he can demand the **Developer** to rewrite the documentation with the **Documentation Engineers** assistance.
| Not a bug | It is a normal behavior in accordance with the specification of the product. |
| No change required | The issue didnt require any change of the product, such as a question issue.|
| Suspended | The issue is postponed (for Acknowledged status). |
| Documentation updated | The documentation has been updated to resolve a misunderstanding causing the issue. |
| Wont fix | It is decided to keep the existing behavior. |

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

File diff suppressed because it is too large Load Diff

After

Width:  |  Height:  |  Size: 73 KiB

View File

@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="gp_XY">
<Type Name="gp_XY">
<DisplayString>[{(float)x} {(float)y}]</DisplayString>
</Type>
<Type Name="gp_Pnt2d">
@@ -40,18 +40,25 @@
</Type>
<Type Name="Handle_Standard_Transient">
<DisplayString Condition="entity==0x00000000">NULL</DisplayString>
<DisplayString Condition="entity!=0x00000000">[count={entity->count}]</DisplayString>
<DisplayString Condition="entity!=0x00000000">[cnt={entity->count}]</DisplayString>
<Expand>
<ExpandedItem>*entity</ExpandedItem>
</Expand>
</Type>
<Type Name="NCollection_Handle&lt;*&gt;">
<DisplayString Condition="entity==0x00000000">NULL</DisplayString>
<DisplayString Condition="entity!=0x00000000">[count={entity->count}]</DisplayString>
<DisplayString Condition="entity!=0x00000000">{(void*)entity} [cnt={entity->count}]</DisplayString>
<Expand>
<ExpandedItem>*((NCollection_Handle&lt;$T1&gt;::Ptr*)entity)->myPtr</ExpandedItem>
</Expand>
</Type>
<Type Name="opencascade::handle&lt;*&gt;">
<DisplayString Condition="entity==0x00000000">NULL</DisplayString>
<DisplayString Condition="entity!=0x00000000">{(void*)entity} [cnt={entity->count} {*entity}]</DisplayString>
<Expand>
<ExpandedItem>(opencascade::handle&lt;$T1&gt;::element_type*)entity</ExpandedItem>
</Expand>
</Type>
<Type Name="TCollection_AsciiString">
<DisplayString>{mylength}: {mystring,s}</DisplayString>
</Type>
@@ -101,6 +108,17 @@
</LinkedListItems>
</Expand>
</Type>
<Type Name="NCollection_Sequence&lt;*&gt;">
<DisplayString>NCollection_Sequence [{mySize}]</DisplayString>
<Expand>
<LinkedListItems>
<Size>mySize</Size>
<HeadPointer>myFirstItem</HeadPointer>
<NextPointer>myNext</NextPointer>
<ValueNode>*($T1*)(sizeof(NCollection_SeqNode) + ((char *)this))</ValueNode>
</LinkedListItems>
</Expand>
</Type>
<Type Name="Bnd_B2f">
<AlternativeType Name="Bnd_B2d"></AlternativeType>
<DisplayString Condition="myCenter[0] &gt; 1000000000000000000.">VOID</DisplayString>
@@ -143,4 +161,97 @@
<Type Name="OpenGl_Context">
<DisplayString>[{myGlVerMajor}.{myGlVerMinor}]</DisplayString>
</Type>
<!--ArrayItems Expansion-->
<Type Name="TColStd_Array1OfInteger">
<DisplayString Condition="isAllocated != 1">empty</DisplayString>
<DisplayString>{{size = {myUpperBound - myLowerBound + 1}}}</DisplayString>
<Expand>
<Item Condition="isAllocated == 1" Name="[size]">myUpperBound - myLowerBound + 1</Item>
<ArrayItems Condition="isAllocated == 1">
<Size>myUpperBound - myLowerBound + 1</Size>
<ValuePointer>(Standard_Integer*)(myStart) + myLowerBound</ValuePointer>
</ArrayItems>
</Expand>
</Type>
<Type Name="TColStd_Array1OfReal">
<DisplayString Condition="isAllocated != 1">empty</DisplayString>
<DisplayString>{{size = {myUpperBound - myLowerBound + 1}}}</DisplayString>
<Expand>
<Item Condition="isAllocated == 1" Name="[size]">myUpperBound - myLowerBound + 1</Item>
<ArrayItems Condition="isAllocated == 1">
<Size>myUpperBound - myLowerBound + 1</Size>
<ValuePointer>(Standard_Real*)(myStart) + myLowerBound</ValuePointer>
</ArrayItems>
</Expand>
</Type>
<!--Multi-dimensional Arrays-->
<Type Name="TColStd_Array2OfInteger">
<DisplayString Condition="(myUpperColumn == myLowerColumn) &amp;&amp; (myUpperRow == myLowerRow)">empty</DisplayString>
<DisplayString>extent = {(myUpperColumn-myLowerColumn+1) * (myUpperRow-myLowerRow+1)}</DisplayString>
</Type>
<!--LinkedListItems Expansion-->
<Type Name="TColStd_ListNodeOfListOfInteger">
<DisplayString>{{current = {myValue}}}</DisplayString>
<Expand>
<LinkedListItems>
<HeadPointer>this</HeadPointer>
<NextPointer>(TColStd_ListNodeOfListOfInteger*)myNext</NextPointer>
<ValueNode>this-&gt;myValue</ValueNode>
</LinkedListItems>
</Expand>
</Type>
<Type Name="TColStd_ListOfInteger">
<DisplayString Condition="myFirst == 0">empty</DisplayString>
<Expand>
<Item Name="values">(TColStd_ListNodeOfListOfInteger*)(myFirst)</Item>
</Expand>
</Type>
<Type Name="TColStd_ListNodeOfListOfReal">
<DisplayString>{{current = {myValue}}}</DisplayString>
<Expand>
<LinkedListItems>
<HeadPointer>this</HeadPointer>
<NextPointer>(TColStd_ListNodeOfListOfReal*)myNext</NextPointer>
<ValueNode>this-&gt;myValue</ValueNode>
</LinkedListItems>
</Expand>
</Type>
<Type Name="TColStd_ListOfReal">
<DisplayString Condition="myFirst == 0">empty</DisplayString>
<Expand>
<Item Name="values">(TColStd_ListNodeOfListOfReal*)(myFirst)</Item>
</Expand>
</Type>
<Type Name="BRep_ListOfCurveRepresentation">
<DisplayString Condition="myFirst == 0">empty</DisplayString>
<Expand>
<Item Name="values">(BRep_ListNodeOfListOfCurveRepresentation*)(myFirst)</Item>
</Expand>
</Type>
<Type Name="TopoDS_Shape">
<DisplayString>{myOrient} {myTShape} loc={myLocation}</DisplayString>
</Type>
<Type Name="TopoDS_TShape">
<DisplayString>subshapes={myShapes} flags={myFlags}</DisplayString>
</Type>
<Type Name="BOPDS_Pave">
<DisplayString>{{{myIndex} {myParameter}}}</DisplayString>
</Type>
<Type Name="BOPDS_PaveBlock">
<DisplayString>edge={myEdge} orig={myOriginalEdge} pave1={myPave1} pave2={myPave2} extpaves={myExtPaves}</DisplayString>
</Type>
</AutoVisualizer>

View File

@@ -136,7 +136,7 @@ dev_guides/svn/svn.md
**Note** that the order of paths to documents in *FILES.txt* is reproduced in the Table of Contents in the HTML output. Please, place them logically.
**Note** that you should specify a file tag, not the document name. See <a href="#OCCT_DM_SECTION_A_1">Header section</a> for details.
**Note** that you should specify a file tag, not the document name. See @ref OCCT_DM_SECTION_A_1 "Header and hierarchic document structure" section for details.
@section OCCT_DOC_SECTION_5 Additional Resources

View File

@@ -97,25 +97,14 @@ The official repository contains:
@subsubsection occt_gitguide_2_1_1 Installation of Git for Windows
Download Git for Windows distributive from http://code.google.com/p/msysgit/downloads/list.
Download Git for Windows distributive from https://git-for-windows.github.io/
During the installation:
* Select Windows Explorer integration options:
* Git Bash Here
* Git GUI Here
@image html OCCT_GitGuide_V2_image001.png
@image latex OCCT_GitGuide_V2_image001.png
* To avoid a mess in your PATH, we recommend selecting Run Git from Windows Prompt in the environment settings dialog:
@image html OCCT_GitGuide_V2_image002.png
@image latex OCCT_GitGuide_V2_image002.png
* Check-in "Windows Explorer integration" options:
* "Git Bash Here";
* "Git GUI Here".
* To avoid a mess in your PATH, we recommend selecting "Run Git from Windows Prompt" in the environment settings dialog:
* In "Configuring the line ending conversions" dialog, select "Checkout Windows-style, commit Unix style endings".
@image html OCCT_GitGuide_V2_image003.png
@image latex OCCT_GitGuide_V2_image003.png
Note that by default Git user interface is localized to the system default language.
If you prefer to work with the English interface, remove or rename .msg localization file
@@ -128,15 +117,12 @@ The official repository contains:
Download TortoiseGit distributive from http://code.google.com/p/tortoisegit/downloads/list.
Launch the installation.
* Select your SSH client. Choose OpenSSH if you prefer to use command-line tools
for SSH keys generation, or TortoisePLink if you prefer to use GUI tool (PuttyGen, see 3.2):
@image html OCCT_GitGuide_V2_image004.png
@image latex OCCT_GitGuide_V2_image004.png
* Complete the installation.
* Select your SSH client. Choose option
* "OpenSSH, Git default SSH Client" if you prefer to use command-line tools for SSH keys generation, or
* "TortoisePLink, coming from Putty, integrates with Windows better" if you prefer to use GUI tool (PuttyGen, see 3.2).
* Complete the installation.
TortoiseGit integrates to Windows Explorer, thus it is possible to use context menu in Windows Explorer to access its functionality:
TortoiseGit integrates into Windows Explorer, thus it is possible to use context menu in Windows Explorer to access its functionality:
@image html OCCT_GitGuide_V2_image005.png
@image latex OCCT_GitGuide_V2_image005.png
@@ -250,11 +236,10 @@ The official repository contains:
@subsection occt_gitguide_3_3 Adding public key in your account
Log in on the portal http://dev.opencascade.org and click on **My account** link to the right. If you have a Contributor status, you will see **SSH keys** tab to the right.
Click on that tab, then click **Add a public key**, and paste the text of the public key (see above sections on how to generate the key) into the text box.
Click **Save** to input the key to the system.
@image html OCCT_GitGuide_V2_image008.png
@image latex OCCT_GitGuide_V2_image008.png
Click **Save** to input the key to the system.
Note that a user can have several SSH keys.
You can distinguish between these keys by the Title field ID; by default it is taken from SSH key comment.
@@ -335,10 +320,6 @@ In the console:
In TortoiseGit:
* Go to the local copy of the repository.
* Right-click in the Explorer window, then choose **Git Create Branch**.
@image html OCCT_GitGuide_V2_image011.png
@image latex OCCT_GitGuide_V2_image011.png
* Select **Base On** Branch *remotes/origin/master*.
@image html OCCT_GitGuide_V2_image012.png
@@ -539,7 +520,7 @@ To rebase your branch into a single commit, you need to do the following:
Use of TortoiseGit is recommended for convenient code review:
* Fetch the changes from the remote repository as described in <a href="#occt_gitguide_4_7">Synchronizing with remote repository</a> section.
* Fetch the changes from the remote repository as described in @ref occt_gitguide_4_7 "Synchronizing with remote repository" section.
* Right-click on the repository, choose **TortoiseGit** -> **Show** log;
* Locate the remote branch you need to review;
* To review commits one-by-one, select each commit in the log. The list of changed files is shown at the bottom of the window; double-click on the file will open visual compare tool.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.6 KiB

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.8 KiB

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.3 KiB

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.1 KiB

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.6 KiB

After

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.2 KiB

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 167 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.2 KiB

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.6 KiB

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 55 KiB

After

Width:  |  Height:  |  Size: 71 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 60 KiB

After

Width:  |  Height:  |  Size: 70 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 59 KiB

After

Width:  |  Height:  |  Size: 76 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 95 KiB

After

Width:  |  Height:  |  Size: 104 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.0 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

@@ -3,15 +3,15 @@
@tableofcontents
@section testmanual_1 Introduction
@section testmanual_intro Introduction
This document provides OCCT developers and contributors with an overview and practical guidelines for work with OCCT automatic testing system.
Reading the Introduction should be sufficient for developers to use the test system to control non-regression of the modifications they implement in OCCT. Other sections provide a more in-depth description of the test system, required for modifying the tests and adding new test cases.
@subsection testmanual_1_1 Basic Information
@subsection testmanual_intro_basic Basic Information
OCCT automatic testing system is organized around DRAW Test Harness @ref occt_user_guides__test_harness "DRAW Test Harness", a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands.
OCCT automatic testing system is organized around @ref occt_user_guides__test_harness "DRAW Test Harness", a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands.
Standard OCCT tests are included with OCCT sources and are located in subdirectory *tests* of the OCCT root folder. Other test folders can be included in the test system, e.g. for testing applications based on OCCT.
@@ -21,7 +21,7 @@ The tests are organized in three levels:
* Grid: a set of test cases within a group, usually aimed at testing some particular aspect or mode of execution of the relevant functionality (e.g. buildevol);
* Test case: a script implementing an individual test (e.g. K4).
See <a href="#testmanual_5_1">Test Groups</a> for the current list of available test groups and grids.
See @ref testmanual_5_1 "Test Groups" chapter for the current list of available test groups and grids.
Some tests involve data files (typically CAD models) which are located separately and are not included with OCCT code. The archive with publicly available test data files should be downloaded and installed independently on OCCT sources (see http://dev.opencascade.org).
@@ -98,7 +98,7 @@ Example:
Detailed logs are saved in D:/occt/results_2012-06-04T0919
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The tests are considered as non-regressive if only OK, BAD (i.e. known problem), and SKIPPED (i.e. not executed, typically because of lack of a data file) statuses are reported. See <a href="#testmanual_3_5">Interpretation of test results</a> for details.
The tests are considered as non-regressive if only OK, BAD (i.e. known problem), and SKIPPED (i.e. not executed, typically because of lack of a data file) statuses are reported. See @ref testmanual_details_results "Interpretation of test results" for details.
The results and detailed logs of the tests are saved by default to a new subdirectory of the subdirectory *results* in the current folder, whose name is generated automatically using the current date and time, prefixed by Git branch name (if Git is available and current sources are managed by Git).
If necessary, a non-default output directory can be specified using option <i> outdir</i> followed by a path to the directory. This directory should be new or empty; use option <i>overwrite</i> to allow writing results in the existing non-empty directory.
@@ -165,14 +165,14 @@ test: Run specified test case
This key will be ignored if the "-echo" key is already set.
~~~~~
@subsubsection testmanual_1_3_4 Creating a New Test
@subsubsection testmanual_intro_quick_create Creating a New Test
The detailed rules of creation of new tests are given in <a href="#testmanual_3">section 3</a>. The following short description covers the most typical situations:
The detailed rules of creation of new tests are given in @ref testmanual_3 "Creation and modification of tests" chapter. The following short description covers the most typical situations:
Use prefix <i>bug</i> followed by Mantis issue ID and, if necessary, additional suffixes, for naming the test script, data files, and DRAW commands specific for this test case.
1. If the test requires C++ code, add it as new DRAW command(s) in one of files in *QABugs* package.
2. Add script(s) for the test case in the subfolder corresponding to the relevant OCCT module of the group *bugs* <i>($CASROOT/tests/bugs)</i>. See <a href="#testmanual_5_2">the correspondence map</a>.
2. Add script(s) for the test case in the subfolder corresponding to the relevant OCCT module of the group *bugs* <i>($CASROOT/tests/bugs)</i>. See @ref testmanual_5_2 "the correspondence map".
3. In the test script:
* Load all necessary DRAW modules by command *pload*.
* Use command *locate_data_file* to get a path to data files used by test script. (Make sure to have this command not inside catch statement if it is used.)
@@ -288,7 +288,7 @@ This file is a TCL script. It is executed after every test in the current group.
Note: *TEST COMPLETED* string should be present in the output to indicate that the test is finished without crash.
See <a href="#testmanual_3">section 3</a> for more information.
See @ref testmanual_3 "Creation and modification of tests" chapter for more information.
Example:
~~~~~
@@ -321,7 +321,7 @@ Example:
Lines starting with a *#* character and blank lines are ignored to allow comments and spacing.
See <a href="#testmanual_3_5">Interpretation of test results</a> chapter for details.
See @ref testmanual_details_results "Interpretation of test results" chapter for details.
If a line matches several rules, the first one applies. Rules defined in the grid are checked first, then rules in the group, then rules in the test root directory. This allows defining some rules on the grid level with status *IGNORE* to ignore messages that would otherwise be treated as errors due to the group level rules.
@@ -334,7 +334,7 @@ Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection testmanual_2_2_6 Directory "data"
The test group may contain subdirectory *data*, where test scripts shared by different test grids can be put. See also <a href="#testmanual_2_3_5">Directory *data*</a>.
The test group may contain subdirectory *data*, where test scripts shared by different test grids can be put. See also @ref testmanual_2_3_5 "Directory data".
@subsection testmanual_2_3 Test Grids
@@ -440,7 +440,7 @@ This section describes how to add new tests and update existing ones.
The new tests are usually added in the frame of processing issues in OCCT Mantis tracker.
Such tests in general should be added to group bugs, in the grid
corresponding to the affected OCCT functionality. See <a href="#testmanual_5_2">Mapping of OCCT functionality to grid names in group *bugs*</a>.
corresponding to the affected OCCT functionality. See @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs".
New grids can be added as necessary to contain tests for the functionality not yet covered by existing test grids.
The test case name in the bugs group should be prefixed by the ID of the corresponding issue in Mantis (without leading zeroes) with prefix *bug*. It is recommended to add a suffix providing a hint on the tested situation. If more than one test is added for a bug, they should be distinguished by suffixes; either meaningful or just ordinal numbers.
@@ -563,7 +563,7 @@ In order to ensure that the test works as expected in different environments, ob
* Do not put call to *locate_data_file* in catch statement this can prevent correct interpretation of the missing data file by the test system.
* Do not use commands *decho* and *dlog* in the test script, to avoid interference with use of these commands by the test system.
@subsection testmanual_3_5 Interpretation of test results
@subsection testmanual_details_results Interpretation of test results
The result of the test is evaluated by checking its output against patterns defined in the files *parse.rules* of the grid and group.
@@ -786,7 +786,7 @@ Grids names are based on name of the command used, with suffixes:
This group allows testing cases coming from Mantis issues.
The grids are organized following OCCT module and category set for the issue in the Mantis tracker.
See <a href="#testmanual_5_2">Mapping of OCCT functionality to grid names in group *bugs*</a> for details.
See @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs" chapter for details.
@subsubsection testmanual_5_1_5 caf

View File

@@ -5,53 +5,53 @@ Upgrade from older OCCT versions {#occt_dev_guides__upgrade}
@section upgrade_intro Introduction
This document provides technical details on changes made in particular versions of OCCT, and is aimed to help upgrading user applications based on previous versions of OCCT to newer ones.
This document provides technical details on changes made in particular versions of OCCT. It can help to upgrade user applications based on previous versions of OCCT to newer ones.
@subsection upgrade_intro_precautions Precautions
Back-up your code before upgrade.
We strongly recommend using version control system during upgrade process, saving one or several commits for each step of upgrade, until overall result is verified.
This will facilitate identification and correction of possible problems that can occur on intermediate steps of upgrade.
Carefully document each step to be able to repeat it if necessary.
Back-up your code before the upgrade.
We strongly recommend using version control system during the upgrade process and saving one or several commits at each step of upgrade, until the overall result is verified.
This will facilitate identification and correction of possible problems that can occur at the intermediate steps of upgrade.
It is advisable to document each step carefully to be able to repeat it if necessary.
@subsection upgrade_intro_disclaim Disclaimer
This document describes known issues that have been encountered in porting of OCCT and some applications, and approaches that helped to resolve these issues in known cases.
This document describes known issues that have been encountered during porting of OCCT and some applications and approaches that have helped to resolve these issues in known cases.
It does not pretend to cover all possible migration issues that can appear in your application.
Please take this document with discretion; apply your expertise and knowledge of your application to ensure correct result.
Take this document with discretion; apply your expertise and knowledge of your application to ensure the correct result.
The automatic upgrade tool is provided as-is, without warranty of any kind, and we explicitly disclaim any liability for possible errors that may appear due to use of this tool.
The automatic upgrade tool is provided as is, without warranty of any kind, and we explicitly disclaim any liability for possible errors that may appear due to use of this tool.
It is your responsibility to ensure that the changes you made in your code are correct.
When upgrading your code by automatic script, make sure to carefully review the changes made by it, on each step, before committing them.
When you upgrade the code by an automatic script, make sure to carefully review the introduced changes at each step before committing them.
@section upgrade_700 Upgrade to OCCT 7.0.0
@subsection upgrade_700_persist Removal of legacy persistence
Legacy persistence for shapes and OCAF data based on Storage_Schema (toolkits TKShapeShcema, TLStdLSchema, TKStdSchema, TKXCAFSchema) has been removed in OCCT 7.0.0.
Applications that used these persistence tools for their data need to be updated to use other persistence mechanisms.
Legacy persistence for shapes and OCAF data based on *Storage_Schema* (toolkits *TKShapeShcema, TLStdLSchema, TKStdSchema* and *TKXCAFSchema*) has been removed in OCCT 7.0.0.
The applications that used these data persistence tools need to be updated to use other persistence mechanisms.
The existing data files in standard formats can be converted using OCCT 6.9.0 or previous version, as follows.
The existing data files in standard formats can be converted using OCCT 6.9.0 or a previous version, as follows.
#### CSFDB files
Files in CSFDB format (usually with extension .csfdb) contain OCCT shape data that can be converted to BRep format.
The easiest way to do that is to use ImportExport sample provided with OCCT 6.9.0 (or earlier):
- Start ImportExport sample
- Select File / New
- Select File / Import / CSFDB... and specify the file to be converted
- Drag mouse with right button pressed across the view to select all shapes by rectangle
- Select File / Export / BREP... and specify location and name for the resulting file
- Start ImportExport sample;
- Select File / New;
- Select File / Import / CSFDB... and specify the file to be converted;
- Drag the mouse with the right button pressed across the view to select all shapes by the rectangle;
- Select File / Export / BREP... and specify the location and name for the resulting file
#### OCAF and XCAF documents
Files containing OCAF data saved in old format usually have extensions .std or .sgd or .dxc (XDE documents).
Files containing OCAF data saved in the old format usually have extensions <i>.std, .sgd</i> or <i>.dxc</i> (XDE documents).
These files can be converted to XML or binary OCAF formats using DRAW Test Harness commands available in OCCT 6.9.0 or earlier.
For that, start *DRAWEXE* and perform the following commands:
* for the conversion of the "*.std" and "*.sgd" file formats to the binary format "*.cbf" (Created document should be in **BinOcaf** format instead of **MDTV-Standard**):
* To convert <i>*.std</i> and <i>*.sgd</i> file formats to binary format <i>*.cbf</i> (The created document should be in *BinOcaf* format instead of *MDTV-Standard*):
@code
Draw[]> pload ALL
@@ -60,7 +60,7 @@ For that, start *DRAWEXE* and perform the following commands:
Draw[]> SaveAs Doc [path to the new file]
@endcode
* for the conversion of the "*.dxc" file format to the binary format "*.xbf" (Created document should be in **BinXCAF** format instead of **MDTV-XCAF**):
* To convert <i>*.dxc</i> file format to binary format <i>*.xbf</i> (The created document should be in *BinXCAF* format instead of *MDTV-XCAF*):
@code
Draw[]> pload ALL
@@ -69,24 +69,26 @@ For that, start *DRAWEXE* and perform the following commands:
Draw[]> XSave Doc [path to the new file]
@endcode
On Windows, be careful to replace back slashes in the file path by either direct slash or pairs of back slashes.
Use "XmlOcaf" or "XmlXCAF" instead of "BinOcaf" and "BinXCAF", respectively, to save in XML format instead of binary one.
On Windows, it is necessary to replace back slashes in the file path by direct slashes or pairs of back slashes.
Use *XmlOcaf* or *XmlXCAF* instead of *BinOcaf* and *BinXCAF*, respectively, to save in XML format instead of binary one.
@subsection upgrade_occt700_cdl Removal of CDL and WOK
OCCT code has been completely refactored in version 7.0 to get rid of obsolete technologies used since its inception: CDL (Cas.Cade Definition Language) and WOK (Workshop Organization Kit).
C++ code previously generated by WOK from CDL declarations is now included directly in OCCT sources.
This modification did not change names, API, and behavior of existing OCCT classes, thus in general the code based on OCCT 6.x should compile and work fine with OCCT 7.0.
However, due to redesign of basic mechanisms (CDL generic classes, Handles and RTTI) using C++ templates, some changes may be necessary in the code when porting to OCCT 7.0, as described below.
WOK is not necessary anymore for building OCCT from sources, though it still can be used in traditional way -- auxiliary files required for that are preserved.
WOK is not necessary anymore for building OCCT from sources, though it still can be used in a traditional way -- auxiliary files required for that are preserved.
The recommended method for building OCCT 7.x is CMake, see @ref occt_dev_guides__building_cmake.
Alternative solution is to use legacy generator of project files (extracted from WOK), see @ref occt_dev_guides__building_wok.
The alternative solution is to use legacy generator of project files (extracted from WOK), see @ref occt_dev_guides__building_wok.
@subsubsection upgrade_occt700_cdl_auto Automatic upgrade
Most of typical changes required for upgrading code to use OCCT 7.0 can be done automatically using the *upgrade* tool included in OCCT 7.0.
Most of typical changes required for upgrading code for OCCT 7.0 can be done automatically using the *upgrade* tool included in OCCT 7.0.
This tool is a Tcl script, thus Tcl should be available on your workstation to run it.
Example:
@@ -96,49 +98,54 @@ Example:
% upgrade -recurse -all -src=<path_to_your_sources>
~~~~~
On Windows, helper batch script upgrade.bat can be used, provided that Tcl is either available in PATH, or configured via custom.bat script (for instance, if you use OCCT installed from Windows installer package). Start it from command prompt:
On Windows, the helper batch script *upgrade.bat* can be used, provided that Tcl is either available in *PATH*, or configured via *custom.bat* script (for instance, if you use OCCT installed from Windows installer package). Start it from the command prompt:
~~~~~
cmd> <path_to_occt>\upgrade.bat -recurse -all -inc=<path_to_occt>\inc -src=<path_to_your_sources> [options]
~~~~~
Run upgrade tool without arguments to see the list of available options.
Run the upgrade tool without arguments to see the list of available options.
Upgrade tool performs the following changes in the code.
The upgrade tool performs the following changes in the code.
1. Adds second argument to macro DEFINE_STANDARD_RTTI indicating base class for its argument class (if inheritance is recognized by the script):
1. Replaces macro *DEFINE_STANDARD_RTTI* by *DEFINE_STANDARD_RTTIEXT*, with second argument indicating base class for the main argument class (if inheritance is recognized by the script):
~~~~~
DEFINE_STANDARD_RTTI(Class) -> DEFINE_STANDARD_RTTI(Class, Base)
DEFINE_STANDARD_RTTI(Class) -> DEFINE_STANDARD_RTTIEXT(Class, Base)
~~~~~
2. Replaces forward declarations of collection classes previously generated from CDL generics (defined in TCollection package) by \#include of corresponding header:
@note If macro *DEFINE_STANDARD_RTTI* with two arguments (used in intermediate development versions of OCCT 7.0) is found, the script will convert it to either *DEFINE_STANDARD_RTTIEXT* or *DEFINE_STANDARD_RTTI_INLINE*.
The former case is used if current file is header and source file with the same name is found in the same folder.
In this case, macro *IMPLEMENT_STANDARD_RTTI* is injected in the corresponding source file.
The latter variant defines all methods for RTTI as inline, and does not require *IMPLEMENT_STANDARD_RTTIEXT* macro.
2. Replaces forward declarations of collection classes previously generated from CDL generics (defined in *TCollection* package) by inclusion of the corresponding header:
~~~~~
class TColStd_Array1OfReal; -> #include <TColStd_Array1OfReal.hxx>
~~~~~
3. Replaces underscored names of Handle classes by usage of a macro:
3. Replaces underscored names of *Handle* classes by usage of a macro:
~~~~~
Handle_Class -> Handle(Class)
~~~~~
This change is not applied if source or header file is recognized as containing definition of Qt class with signals or slots, to avoid possible compilation errors of MOC files caused by inability of MOC to recognize macros (see http://doc.qt.io/qt-4.8/signalsandslots.html).
The file is considered as defining Qt object if it contains strings "Q_OBJECT" and either "slots:" or "signals".
This change is not applied if the source or header file is recognized as containing the definition of Qt class with signals or slots, to avoid possible compilation errors of MOC files caused by inability of MOC to recognize macros (see http://doc.qt.io/qt-4.8/signalsandslots.html).
The file is considered as defining a Qt object if it contains strings *Q_OBJECT* and either *slots:* or *signals:*.
4. Removes forward declarations of classes with names Handle(C) or Handle_C, replacing these either by forward declaration of its argument class, or (for files defining Qt objects) \#include statement for header with name of the argument class and extension .hxx:
4. Removes forward declarations of classes with names <i>Handle(C)</i> or *Handle_C*, replacing them either by forward declaration of its argument class, or (for files defining Qt objects) <i>\#include</i> statement for a header with the name of the argument class and extension .hxx:
~~~~~
class Handle(TColStd_HArray1OfReal); -> #include <TColStd_HArray1OfReal.hxx>
~~~~~
5. Removes \#includes of files Handle_...hxx disappeared in OCCT 7.0:
5. Removes <i> \#includes </i> of files <i>Handle_...hxx</i> that have disappeared in OCCT 7.0:
~~~~~
#include <Handle_Geom_Curve.hxx> ->
~~~~~
6. Removes typedef statements that use Handle macro to generate name:
6. Removes *typedef* statements that use *Handle* macro to generate the name:
~~~~~
typedef NCollection_Handle<Message_Msg> Handle(Message_Msg); ->
~~~~~
7. Converts C-style casts applied to Handles to calls to DownCast() method:
7. Converts C-style casts applied to Handles into calls to <i>DownCast()</i> method:
~~~~~
((Handle(A)&)b) -> Handle(A)::DownCast(b)
(Handle(A)&)b -> Handle(A)::DownCast(b)
@@ -147,21 +154,23 @@ typedef NCollection_Handle<Message_Msg> Handle(Message_Msg); ->
(*(Handle(A)*)&b) -> Handle(A)::DownCast(b)
~~~~~
8. Moves Handle() macro out of namespace scope:
8. Moves <i>Handle()</i> macro out of namespace scope:
~~~~~
Namespace::Handle(Class) -> Handle(Namespace::Class)
~~~~~
9. Converts local variables of reference type initialized by temporary object returned by call to DownCast(), to non-references (to avoid using reference to destroyed memory):
9. Converts local variables of reference type, which are initialized by a temporary object returned by call to <i>DownCast()</i>, to the variables of non-reference type (to avoid using references to destroyed memory):
~~~~~
const Handle(A)& a = Handle(B)::DownCast (b); -> Handle(A) a (Handle(B)::DownCast (b));
~~~~~
10. Adds \#include for all classes used as argument to macro STANDARD_TYPE(), except of already included ones;
10. Adds <i>\#include</i> for all classes used as argument to macro <i>STANDARD_TYPE()</i>, except for already included ones;
11. Removes uses of obsolete macros IMPLEMENT_DOWNCAST() and IMPLEMENT_STANDARD_*().
11. Removes uses of obsolete macros *IMPLEMENT_DOWNCAST* and *IMPLEMENT_STANDARD_*..., except *IMPLEMENT_STANDARD_RTTIEXT*.
> If you plan to keep compatibility of your code with older versions of OCCT, add option "-compat" to avoid the latter change. See also @ref upgrade_occt700_cdl_compat.
@note If you plan to keep compatibility of your code with older versions of OCCT, add option <i>-compat</i> to avoid this change. See also @ref upgrade_occt700_cdl_compat.
.
As long as the upgrade routine runs, some information messages are sent to the standard output.
In some cases the warnings or errors like the following may appear:
@@ -170,20 +179,20 @@ In some cases the warnings or errors like the following may appear:
Error in {HEADER_FILE}: Macro DEFINE_STANDARD_RTTI used for class {CLASS_NAME} whose declaration is not found in this file, cannot fix
~~~~~
Be sure to check carefully all reported errors and warnings, as corresponding places likely will require manual corrections.
In some cases these messages may help you to detect errors in your code, for instance, cases where DEFINE_STANDARD_RTTI macro passes invalid class name as an argument.
Be sure to check carefully all reported errors and warnings, as the corresponding code will likely require manual corrections.
In some cases these messages may help you to detect errors in your code, for instance, cases where *DEFINE_STANDARD_RTTI* macro is used with incorrect class name as an argument.
@subsubsection upgrade_occt700_cdl_compiler Possible compiler errors
Some situations requiring upgrade cannot be detected and / or handled by automatic procedure.
If you get compiler errors or warnings when trying to build upgraded code, you will need to fix them manually.
Some situations requiring upgrade cannot be detected and / or handled by the automatic procedure.
If you get compiler errors or warnings when trying to build the upgraded code, you will need to fix them manually.
The following paragraphs list known situations of this kind.
#### Missing header files
Use of handle objects (construction, comparison using operators == or !=, use of function STANDRAD_TYPE() and method DownCast()) now requires the type of the object pointed by Handle to be completely known at compile time. Thus it may be necessary to include header of the corresponding class to make the code compilable.
The use of handle objects (construction, comparison using operators == or !=, use of function <i>STANDRAD_TYPE()</i> and method <i>DownCast()</i>) now requires the type of the object pointed by Handle to be completely known at compile time. Thus it may be necessary to include header of the corresponding class to make the code compilable.
For example, the following lines will fail to compile if Geom_Line.hxx is not included:
For example, the following lines will fail to compile if *Geom_Line.hxx* is not included:
~~~~~
Handle(Geom_Line) aLine = 0;
@@ -198,8 +207,8 @@ This will eliminate the need to include the header *A* in each source file where
#### Ambiguity of calls to overloaded functions
This issue appears in compilers that do not support default arguments in template functions (known cases are Visual C++ 10 and 11): compiler reports ambiguity error if handle is used in argument of call to function that has two or move overloaded versions, accepting handles to different types.
The problem is that operator const handle<T2>& is defined for any type T2, thus compiler cannot make a right choice.
This issue appears in the compilers that do not support default arguments in template functions (known cases are Visual C++ 10 and 11): the compiler reports an ambiguity error if a handle is used in the argument of a call to the function that has two or move overloaded versions, accepting handles to different types.
The problem is that operator <i> const handle<T2>& </i> is defined for any type *T2*, thus the compiler cannot make the right choice.
Example:
~~~~~
@@ -210,14 +219,14 @@ Handle(Geom_TrimmedCurve) aCurve = new Geom_TrimmedCurve (...);
func (aCurve); // ambiguity error in VC++ 10
~~~~~
To resolve this ambiguity, change your code so that argument type corresponds exactly to the function signature.
In some cases this can be done by using relevant type for the corresponding variable, like in the example above:
To resolve this ambiguity, change your code so that argument type should correspond exactly to the function signature.
In some cases this can be done by using the relevant type for the corresponding variable, like in the example above:
~~~~~
Handle(Geom_Curve) aCurve = new Geom_TrimmedCurve (...);
~~~~~
Other variants are assigning the argument to local variable of correct type, using direct cast or constructor:
Other variants consist in assigning the argument to a local variable of the correct type and using the direct cast or constructor:
~~~~~
const Handle(Geom_Curve)& aGCurve (aTrimmedCurve);
@@ -226,12 +235,12 @@ func (static_cast(aCurve)); // OK - direct cast
func (Handle(Geom_Curve)(aCurve)); // OK - temporary handle is constructed
~~~~~
Another possibility is defining additional templated variant of the overloaded function causing ambiguity, and use SFINAE to resolve the ambiguity.
For example of this technique, see definition of the template variant of the method IGESData_IGESWriter::Send().
Another possibility consists in defining additional template variant of the overloaded function causing ambiguity, and using *SFINAE* to resolve the ambiguity.
This technique can be illustrated by the definition of the template variant of method <i>IGESData_IGESWriter::Send()</i>.
#### Lack of implicit cast to base type
Due to the fact that now cast of handle to reference to handle to the base type is user-defined operation, conversions that require this cast combined with other user-defined cast will not be resolved automatically by compiler.
As the cast of a handle to the reference to another handle to the base type has become a user-defined operation, the conversions that require this cast together with another user-defined cast will not be resolved automatically by the compiler.
For example:
@@ -239,15 +248,15 @@ For example:
Handle(Geom_Geometry) aC = GC_MakeLine (p, v); // compiler error
~~~~~
The problem here is that class GCE2d_MakeSegment has user-defined conversion to const Handle(Geom_TrimmedCurve)&, which is not the same as type of the local variable aC.
The problem is that the class *GCE2d_MakeSegment* has a user-defined conversion to <i>const Handle(Geom_TrimmedCurve)&,</i> which is not the same as the type of the local variable *aC*.
To resolve this, use method Value():
To resolve this, use method <i>Value()</i>:
~~~~~
Handle(Geom_Geometry) aC = GC_MakeLine (p, v).Value(); // ok
~~~~~
or use variable of appropriate type:
or use variable of the appropriate type:
~~~~~
Handle(Geom_TrimmedCurve) aC = GC_MakeLine (p, v); // ok
@@ -257,7 +266,7 @@ Handle(Geom_TrimmedCurve) aC = GC_MakeLine (p, v); // ok
You might need to clean your code from incorrect use of macros *STANDARD_TYPE*() and *Handle*().
1. Explicit definitions of static functions with names generated by macro STANDARD_TYPE(), which are artifacts of old implementation of RTTI, should be removed.
1. Explicit definitions of static functions with names generated by macro *STANDARD_TYPE()*, which are artifacts of old implementation of RTTI, should be removed.
Example:
~~~~~
@@ -268,7 +277,7 @@ const Handle(Standard_Type)& STANDARD_TYPE(math_GlobOptMin)
}
~~~~~
2. Incorrect location of closing parenthesis of Handle() macro that was not detectable in OCCT 6.x will cause compiler error and must be corrected.
2. Incorrect location of closing parenthesis of *Handle()* macro that was not detectable in OCCT 6.x will cause a compiler error and must be corrected.
Example (note misplaced closing parenthesis):
~~~~~
@@ -277,21 +286,21 @@ aBSpline = Handle( Geom2d_BSplineCurve::DownCast(BS->Copy()) );
#### Use of class Standard_AncestorIterator
Class Standard_AncestorIterator has been removed; use method Parent() of Standard_Type class to parse inheritance chain.
Class *Standard_AncestorIterator* has been removed; use method *Parent()* of *Standard_Type* class to parse the inheritance chain.
#### Absence of cast to Standard_Transient*
Handles in OCCT 7.0 do not have operator of conversion to Standard_Transient*, which was present in earlier versions.
Handles in OCCT 7.0 do not have the operator of conversion to <i>Standard_Transient*,</i> which was present in earlier versions.
This is done to prevent possible unintended errors like this:
~~~~~
Handle(Geom_Line) aLine = ...;
Handle(Geom_Surface) aSurf = ...;
...
if (aLine == aSurf) {...} // will cause compiler error in OCCT 7.0, but not OCCT 6.x
if (aLine == aSurf) {...} // will cause a compiler error in OCCT 7.0, but not OCCT 6.x
~~~~~
Places where this implicit cast has been used should be corrected manually.
The places where this implicit cast has been used should be corrected manually.
The typical situation is when Handle is passed to stream:
~~~~~
@@ -299,15 +308,15 @@ Handle(Geom_Line) aLine = ...;
os << aLine; // in OCCT 6.9.0, resolves to operator << (void*)
~~~~~
Call method get() explicitly to output address of the Handle.
Call method <i>get()</i> explicitly to output the address of the Handle.
@subsubsection upgrade_occt700_cdl_runtime Possible runtime problems
Known situations when problems are possible at run time after upgrade to OCCT 7.0 are listed here.
Here is the list of known possible problems at run time after the upgrade to OCCT 7.0.
#### References to temporary objects
In previous versions, compiler was able to detect situation when local variable of reference type to Handle is initialized by temporary object, and ensured that lifetime of that object is longer than that of the variable.
In previous versions, the compiler was able to detect the situation when a local variable of a "reference to a Handle" type is initialized by temporary object, and ensured that lifetime of that object is longer than that of the variable.
Since OCCT 7.0, it will not work if types of the temporary object and variable are different (due to involvement of user-defined type cast), thus such temporary object will be destroyed immediately.
Example:
@@ -321,47 +330,55 @@ aBC->Transform (T); // access violation in OCCT 7.0
@subsubsection upgrade_occt700_cdl_compat Preserving compatibility with OCCT 6.x
If you like to preserve compatibility of your application code with OCCT versions 6.x even after upgrade to 7.0, consider the following suggestions:
If you like to preserve the compatibility of your application code with OCCT versions 6.x even after the upgrade to 7.0, consider the following suggestions:
1. When running automatic upgrade tool, add option *-compat*.
1. If your code used sequences of macros *IMPLEMENT_STANDARD_*... generated by WOK, replace them by single macro *IMPLEMENT_STANDARD_RTTIEXT*
2. In order to overcome incompatibility of macro DEFINE_STANDARD_RTTI which has additional argument in OCCT 7.0, you can replace (after upgrade) its use in your code by your own version-dependent macro, which resolves to either 6.x or 7.x version.
2. When running automatic upgrade tool, add option <i>-compat</i>.
3. Define macros *DEFINE_STANDARD_RTTIEXT* and *DEFINE_STANDARD_RTTI_INLINE* when building with previous versions of OCCT, resolving to *DEFINE_STANDARD_RTTI* with single argument
Example:
~~~~~
#if OCC_VERSION_HEX < 0x070000
#define DEFINE_STANDARD_RTTI_COMPAT(C1,C2) DEFINE_STANDARD_RTTI(C1)
#else
#define DEFINE_STANDARD_RTTI_COMPAT(C1,C2) DEFINE_STANDARD_RTTI(C1,C2)
#define DEFINE_STANDARD_RTTIEXT(C1,C2) DEFINE_STANDARD_RTTI(C1)
#define DEFINE_STANDARD_RTTI_INLINE(C1,C2) DEFINE_STANDARD_RTTI(C1)
#endif
~~~~~
@subsubsection upgrade_occt700_cdl_wok Applications based on CDL and WOK
If you have application essentially based on CDL, and need to upgrade it to OCCT 7.0, you will very likely need to convert your application code to non-CDL form.
This is non-trivial effort; the required actions would depend strongly on the structure of the code and used features of CDL.
If your application is essentially based on CDL, and you need to upgrade it to OCCT 7.0, you will very likely need to convert your application code to non-CDL form.
This is a non-trivial effort; the required actions would depend strongly on the structure of the code and used CDL features.
The upgrade script and sources of specialized version of WOK used for upgrading OCCT code can be found in WOK Git repository in branch [CR0_700_2](http://git.dev.opencascade.org/gitweb/?p=occt-wok.git;a=log;h=refs/heads/CR0_700_2).
The upgrade script and sources of a specialized WOK version used for OCCT code upgrade can be found in WOK Git repository in branch [CR0_700_2](http://git.dev.opencascade.org/gitweb/?p=occt-wok.git;a=log;h=refs/heads/CR0_700_2).
[Contact us](http://www.opencascade.com/contact/) if you need more help.
@subsection upgrade_occt700_bspline Separation of BSpline cache
Implementation of NURBS curves and surfaces has been revised: cache of polynomial coefficients, used to accelerate calculate values of B-spline, is separated from data objects (Geom2d_BSplineCurve, Geom_BSplineCurve, Geom_BSplineSurface), into dedicated classes (BSplCLib_Cache and BSplSLib_Cache).
Implementation of NURBS curves and surfaces has been revised: the cache of polynomial coefficients, which is used to accelerate calculate values of B-spline, has been separated from data objects *Geom2d_BSplineCurve, Geom_BSplineCurve* and *Geom_BSplineSurface* into the dedicated classes *BSplCLib_Cache* and *BSplSLib_Cache*.
The benefits of this change are:
* Reduced memory footprint of OCCT shapes (up to 20% on some cases)
* Possibility to evaluate the same B-Spline concurrently in parallel threads without data races and mutex locks
The drawback is that direct evaluation of B-Splines using methods of curves and surfaces becomes slower, due to absence of cache. The way to avoid slow down is to use adaptor classes (Geom2dAdaptor_Curve, GeomAdaptor_Curve and GeomAdaptor_Surface): they now use cache when the curve or surface is a B-spline.
The drawback is that direct evaluation of B-Splines using methods of curves and surfaces becomes slower due to the absence of cache. The slow-down can be avoided by using adaptor classes *Geom2dAdaptor_Curve, GeomAdaptor_Curve* and *GeomAdaptor_Surface*, which now use cache when the curve or surface is a B-spline.
OCCT algorithms are changed to use adaptors for B-spline calculations instead of direct methods of curves and surfaces.
The same changes (use of adaptors instead of direct call to curve and surface methods) should be implemented in relevant places in applications based on OCCT in order to get maximum performance.
OCCT algorithms have been changed to use adaptors for B-spline calculations instead of direct methods for curves and surfaces.
The same changes (use of adaptors instead of direct call to curve and surface methods) should be implemented in relevant places in the applications based on OCCT to get the maximum performance.
@subsection upgrade_occt700_booleanresult Structural result of Boolean operations
The result of Boolean operations became structured according to the structure of the input shapes. Therefore it may impact old applications that always iterate on direct children of the result compound assuming to obtain solids as iteration items, regardless of the structure of the input shapes. In order to get always solids as iteration items it is recommended to use TopExp_Explorer instead of TopoDS_Iterator.
@subsection upgrade_occt700_brepextrema BRepExtrema_ExtCC finds one solution only
Extrema computation between non-analytical curves in shape-shape distance calculation algorithm has been changed in order to return only one solution. So, if e.g. two edges are created on parallel b-spline curves the algorithm BRepExtrema_DistShapeShape will return only one solution instead of enormous number of solutions. There is no way to get algorithm working in old manner.
@subsection upgrade_occt700_sorttools Removal of SortTools package
Package SortTools has been removed.
Package *SortTools* has been removed.
The code that used the tools provided by that package should be corrected manually.
The recommended approach is to use sorting algorithms provided by STL.
@@ -382,22 +399,22 @@ can be replaced by:
...
TCollection_Array1OfReal aValues = ...;
...
std::stable_sort (aValues->begin(), aValues->end());
std::stable_sort (aValues.begin(), aValues.end());
~~~~~
@subsection upgrade_occt700_2dlayers On-screen objects and ColorScale
Old mechanism for rendering Underlay and Overlay on-screen 2D objects based on Visual3d_Layer and immediate drawing model (e.g. uncached and thus slow) have been removed.
Classes Aspect_Clayer2d, OpenGl_GraphicDriver_Layer, Visual3d_Layer, Visual3d_LayerItem, V3d_LayerMgr, V3d_LayerMgrPointer have been deleted.
The old mechanism for rendering Underlay and Overlay on-screen 2D objects based on *Visual3d_Layer* and immediate drawing model (uncached and thus slow) has been removed.
Classes *Aspect_Clayer2d, OpenGl_GraphicDriver_Layer, Visual3d_Layer, Visual3d_LayerItem, V3d_LayerMgr* and *V3d_LayerMgrPointer* have been deleted.
General AIS interactive objects with transformation persistence flag Graphic3d_TMF_2d can be used as replacement of Visual3d_LayerItem.
Anchor point specified for transformation persistence defines a corner of window (or center in case of (0, 0) point).
To keep on-screen 2D objects on the top of main screen, them could be assigned to appropriate Z-layer.
Predefined Z-layers Graphic3d_ZLayerId_TopOSD and Graphic3d_ZLayerId_BotOSD are intended to replace Underlay and Overlay layers within old API.
General AIS interactive objects with transformation persistence flag *Graphic3d_TMF_2d* can be used as a replacement of *Visual3d_LayerItem*.
The anchor point specified for transformation persistence defines the window corner of (or center in case of (0, 0) point).
To keep on-screen 2D objects on top of the main screen, they can be assigned to the appropriate Z-layer.
Predefined Z-layers *Graphic3d_ZLayerId_TopOSD* and *Graphic3d_ZLayerId_BotOSD* are intended to replace Underlay and Overlay layers within the old API.
ColorScale object previously implemented using Visual3d_LayerItem has been moved to a new class AIS_ColorScale, with width and height specified explicitly.
The property of V3d_View storing global ColorScale object has been removed with associated methods V3d_View::ColorScaleDisplay(), V3d_View::ColorScaleErase(), V3d_View::ColorScaleIsDisplayed(), V3d_View::ColorScale() and classes V3d_ColorScale, V3d_ColorScaleLayerItem, Aspect_ColorScale.
Here is an example of creating ColorScale using updated API:
*ColorScale* object previously implemented using *Visual3d_LayerItem* has been moved to a new class *AIS_ColorScale*, with width and height specified explicitly.
The property of *V3d_View* storing the global *ColorScale* object has been removed with associated methods *V3d_View::ColorScaleDisplay(), V3d_View::ColorScaleErase(), V3d_View::ColorScaleIsDisplayed()* and *V3d_View::ColorScale()* as well as the classes *V3d_ColorScale, V3d_ColorScaleLayerItem* and *Aspect_ColorScale*.
Here is an example of creating *ColorScale* using the updated API:
~~~~~
Handle(AIS_ColorScale) aCS = new AIS_ColorScale();
@@ -414,9 +431,9 @@ aCS->SetToUpdate();
theContextAIS->Display (aCS);
~~~~~
To see how 2d objects are realized in OCCT you can call draw commands vcolorscale, vlayerline or vdrawtext (with -2d option).
Draw command vcolorscale now requires a name of ColorScale object as an argument.
To display this object use command vdisplay. Example:
To see how 2d objects are implemented in OCCT you can call Draw commands *vcolorscale, vlayerline* or *vdrawtext* (with <i>-2d</i> option).
Draw command *vcolorscale* now requires the name of *ColorScale* object as argument.
To display this object use command *vdisplay*. For example:
~~~~~
pload VISUALIZATION
@@ -431,7 +448,7 @@ vlayerline 0 300 300 300 10
vdrawtext t "2D-TEXT" -2d -pos 0 150 0 -color red
~~~~~
Here is a small example in c++ how to display a custom AIS object in 2d:
Here is a small example in C++ illustrating how to display a custom AIS object in 2d:
~~~~~
Handle(AIS_InteractiveContext) aContext = ...;
Handle(AIS_InteractiveObject) anObj =...; // create an AIS object
@@ -444,39 +461,37 @@ aContext->Display (anObj); // display the object
#### Visual3d package
Package Visual3d implementing intermediate layer between high-level V3d classes
Package *Visual3d* implementing the intermediate layer between high-level *V3d* classes
and low-level OpenGl classes for views and graphic structures management has been dropped.
The OpenGl_View inherits from the new class Graphic3d_CView.
Graphic3d_CView is an interface class that declares abstract methods for managing displayed structures,
The *OpenGl_View* inherits from the new class *Graphic3d_CView*.
*Graphic3d_CView* is an interface class that declares abstract methods for managing displayed structures,
display properties and a base layer code that implements computation
and management of HLR (or more broadly speaking view-depended) structures.
In new implementation it takes place of eliminated Visual3d_View.
As before the instance of Graphic3d_CView is still completely managed by V3d_View classes.
It can be accessed through V3d_View interface but normally this should not be required as all its methods are completely wrapped.
In the new implementation it takes place of the eliminated *Visual3d_View*.
As before the instance of *Graphic3d_CView* is still completely managed by *V3d_View* classes.
It can be accessed through *V3d_View* interface but normally it should not be required as all its methods are completely wrapped.
In more details, a concrete specialization of Graphic3d_CView is created and returned by graphical driver on request.
Right after creation the views is directly used for setting rendering properties and adding graphical structures to be displayed.
In more details, a concrete specialization of *Graphic3d_CView* is created and returned by the graphical driver on request.
Right after the creation the views are directly used for setting rendering properties and adding graphical structures to be displayed.
The rendering of graphics is possible after mapping a window and activating the view.
The direct setting of properties makes obsolete usage of intermediate structures with display parameter
like Visual3d_ContextView and etc (the whole package of Visual3d become redundant).
The direct setting of properties obsoletes the use of intermediate structures with display parameter
like *Visual3d_ContextView*, etc. This means that the whole package *Visual3d* becomes redundant.
New location of functionality previously provided by Visual3d package:
- Logic of managing display of structures was put from Visual3d_ViewManager into Graphic3d_StructureManager.
- Removed Visual3d_View class. Logic of managing computed structures was put into base layer of Graphi3d_CView.
- Removed all intermediate structures for storing view parameters e.g. Visual3d_ContextView.
All settings are kept by instances of Graphic3d_CView
- Removed Visual3d_Light intermediate class.
All light properties are still stored in Graphic3d_CLight structure.
The structure is directly access by instance of V3d_Light classes.
- Moved all needed enumerations into Graphic3d package.
The functionality previously provided by *Visual3d* package has been redesigned in the following way :
- The management of display of structures has been moved from *Visual3d_ViewManager* into *Graphic3d_StructureManager*.
- The class *Visual3d_View* has been removed. The management of computed structures has been moved into the base layer of *Graphi3d_CView*.
- All intermediate structures for storing view parameters, e.g. *Visual3d_ContextView*, have been removed.
The settings are now kept by instances of *Graphic3d_CView*.
- The intermediate class *Visual3d_Light* has been removed. All light properties are stored in *Graphic3d_CLight* structure, which is directly accessed by instances of *V3d_Light* classes.
- All necessary enumerations have been moved into *Graphic3d* package.
#### Custom OpenGL rendering and UserDraw
Old APIs based on global callback functions for creating UserDraw objects and for performing custom OpenGL rendering within the view have been dropped.
UserDraw callbacks no more required since OpenGl_Group now inherits Graphic3d_Group and thus can be accessed directly from AIS_InteractiveObject:
Old APIs based on global callback functions for creating *UserDraw* objects and for performing custom OpenGL rendering within the view have been dropped.
*UserDraw* callbacks are no more required since *OpenGl_Group* now inherits *Graphic3d_Group* and thus can be accessed directly from *AIS_InteractiveObject*:
~~~~~
//! Class implementing custom OpenGL element.
@@ -502,7 +517,7 @@ void UserDrawObject::Compute (const Handle(PrsMgr_PresentationManager3d)& thePrs
}
~~~~~
For performing custom OpenGL code within view, user should inherit from class OpenGl_View.
To perform a custom OpenGL code within the view, it is necessary to inherit from class *OpenGl_View*.
See the following code sample:
~~~~~
@@ -556,7 +571,17 @@ public:
@subsection upgrade_occt700_localcontext Deprecation of Local Context
Conception of Local Context has been deprecated.
Related classes (AIS_LocalContext) and methods (AIS_InteractiveContext::OpenLocalContext() and others) will be removed within some future OCCT release.
The conception of Local Context has been deprecated.
The related classes, e.g. *AIS_LocalContext*, and methods ( <i>AIS_InteractiveContext::OpenLocalContext()</i> and others) will be removed in a future OCCT release.
The main functionality provided by Local Context - selection of object subparts - can be now used within Neutral Point without opening any Local Context.
@subsection upgrade_occt700_separate_caf_visualisation Separation of visualization part from TKCAF
Visualization CAF attributes moved into new toolkit TKVCAF.
If your application uses the classes from TPrsStd package then add link to TKVCAF library.
Verson numbers of BinOCAF and XmlOCAF formats are incremented; new files cannot be read by previous versions of OCCT.
For loading OCAF files saved by previous versions and containing attribute TPrsStd_AISPresentation it is necessary that environment variable CSF_MIGRATION_TYPES should be defined, pointing to file src/StdResources/MigrationSheet.txt.
When using documents loaded from a file, make sure to call method TPrsStd_AISViewer::New() prior to accessing TPrsStd_AISPresentation attributes in this document (that method will create them).

View File

@@ -158,7 +158,7 @@ OCCT documentation is provided in several forms:
which is a freeware and can be downloaded from the Adobe site.
- Full reference documentation covering all OCCT classes generated automatically by Doxygen
software is provided in HTML format, in a separate package.
software is provided in HTML format.
Reference documentation is presented in **Modules --> Toolkits --> Packages --> Classes**
logic structure with cross-references to all OCCT classes and complete in-browser search by all classes.
@@ -191,90 +191,64 @@ Linux (x86-64), MAC OS X (x86-64) and Android (4.0.4 armv7) platforms.
The tables below describe the recommended hardware and software configurations
for which OCCT is certified to work.
@subsection OCCT_OVW_SECTION_5_1 Linux
@subsection overview_req_os Operating System
| Operating System | Mandriva 2010, CentOS 5.5, CentOS 6.3, Fedora 17, Fedora 18, Ubuntu 13.04, Debian 6.0\* |
| ----- | ----- |
| Minimum memory | 512 MB, 1 GB recommended |
| Free disk space (complete installation) | 600 MB approx. |
| Video card | See \ref overview_req_graphics |
| Graphic library | OpenGL 3.3+, OpenGL ES 2.0+ |
| C++ | GNU gcc 4.0. - 4.7.3. |
| TCL (for testing tools) | Tcl/Tk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
| Qt (for demonstration tools) | Qt 4.8.6 http://qt-project.org/downloads |
| Freetype (for text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
| FreeImage (optional, for support of common 2D graphic formats) | FreeImage 3.16.0 http://sourceforge.net/projects/freeimage/files |
| gl2ps (optional, for export contents of OCCT viewer to vector graphic files) | gl2ps-1.3.8 http://geuz.org/gl2ps/ |
| Intel TBB (optional, for multithreaded algorithms) | TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ |
| VTK (for VTK Integration Services | VTK 6.1.0 http://www.vtk.org/VTK/resources/software.html |
| OS | Versions |
| --------- | ----------- |
| Windows | 10, 8.1, 7 SP1, Vista SP2 |
| Linux | Mandriva 2010, CentOS 6.3, Fedora 18, Ubuntu 14.10 - 15.10, Debian 6.0, Debian 7.0 |
| OS X | 10.10 Yosemite / 10.9 Mavericks / 10.8 Mountain Lion / 10.7 Lion |
| Android | 6.x, 5.x, 4.0.4+ |
* Debian 6.0 64 bit is a platform used for regular testing of contributions
@subsection overview_req_cpp C++ Compiler / IDE
@subsection OCCT_OVW_SECTION_5_2 Windows
| OS | Compiler |
| --------- | ----------- |
| Windows | Microsoft Visual Studio: 2010 SP1\*, 2012 Update 4, 2013 Update 5, 2015 <br> Intel C++ Composer XE 2013 SP1 |
| Linux | GNU gcc 4.3+ <br> LLVM CLang 3.6+ |
| OS X | XCode 6 or newer |
| Android | NDK r10, GNU gcc 4.8 or newer |
| Operating System | Windows 8.1 / 7 SP1 / Vista SP2 / XP SP3 |
| ----- | ----- |
| Minimum memory | 512 MB, 1 GB recommended |
| Free disk space (complete installation) | 600 MB approx. |
| Video card | See \ref overview_req_graphics |
| Graphic library | OpenGL 3.3+, OpenGL ES 2.0+ |
| C++ | Microsoft Visual Studio: 2005 SP1, 2008 SP1, 2010 SP1 \*, 2012 Update 3, 2013 <br>Intel C++ Composer XE 2013 SP1 |
| TCL (for testing tools) | Tcl/Tk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
| Qt (for demonstration tools) | Qt 4.8.6 http://qt-project.org/downloads |
| Freetype (OCCT Text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
| FreeImage (Support of common graphic formats) | FreeImage 3.16.0 http://sourceforge.net/projects/freeimage/files |
| gl2ps (Export contents of OCCT viewer to vector graphic file) | gl2ps-1.3.8 http://geuz.org/gl2ps/ |
| Intel TBB (optional, for multithreaded algorithms) | TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ |
| VTK (for VTK Integration Services | VTK 6.1.0 http://www.vtk.org/VTK/resources/software.html |
* VC++ 10 64-bit is used for certification of contributions and for building
* VC++ 10 64-bit is used for regular testing and for building
binary package of official release of OCCT on Windows.
@subsection OCCT_OVW_SECTION_5_3 MAC OS X
@subsection overview_req_libs Third-party libraries
| Operating System | OS X 10.10 Yosemite / 10.9 Mavericks / 10.8 Mountain Lion / 10.7 Lion / 10.6.8 Snow Leopard |
| ----- | ----- |
| Component | Requirement |
| --------- | ----------- |
| Graphic library | OpenGL 3.3+, OpenGL ES 2.0+ <br> Direct3D 9 |
| Qt (for samples and demos) | Desktop: Qt 4.8.6+ http://www.qt.io/download/ <br> Android: Qt 5.3.2+ http://www.qt.io/download/ |
| TCL (for testing tools) | Tcl/Tk 8.6.3+ http://www.tcl.tk/software/tcltk/download.html |
| Freetype (for text rendering) | freetype-2.5.3+ http://sourceforge.net/projects/freetype/files/ |
| FreeImage (optional, for support of common 2D graphic formats) | FreeImage 3.16.0+ http://sourceforge.net/projects/freeimage/files |
| gl2ps (optional, for export contents of OCCT viewer to vector formats) | gl2ps-1.3.8+ http://geuz.org/gl2ps/ |
| Intel TBB (optional, for multithreaded algorithms) | TBB 4.x or 5.x http://www.threadingbuildingblocks.org/ |
| VTK (for VTK Integration Services | VTK 6.1+ http://www.vtk.org/VTK/resources/software.html |
@subsection overview_req_hw Hardware
| Component | Requirement |
| --------- | ----------- |
| Minimum memory | 512 MB, 1 GB recommended |
| Free disk space (complete installation) | 600 MB approx. |
| C++ | XCode 3.2 or newer (4.x is recommended) |
| TCL (for testing tools) | Tcl/Tk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
| Qt (for demonstration tools) | Qt 4.8.6 http://qt-project.org/downloads |
| Freetype (OCCT Text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
| FreeImage (Support of common graphic formats) | FreeImage 3.16.0 http://sourceforge.net/projects/freeimage/files |
| gl2ps (Export contents of OCCT viewer to vector graphic file) | gl2ps-1.3.8 http://geuz.org/gl2ps/ |
| Intel TBB (optional, for multithreaded algorithms) | TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ |
@subsection OCCT_OVW_SECTION_5_4 Android
| Operating System | Android 4.0.4+ |
| ----- | ----- |
| Minimum memory | 512 MB, 1 GB recommended |
| C++ | NDK r10, GNU gcc 4.8 or newer |
| Qt (for demonstration tools) | Qt 5.3.2 http://qt-project.org/downloads |
| Freetype (for text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
@subsection overview_req_graphics Graphic cards
On desktop, 3D viewer requires graphic card or software implementation supporting OpenGL 1.1 or above. OpenGL 2.1+ is highly recommended.
Ray tracing requires OpenGL 4.0+ or OpenGL 3.1+ with GL_ARB_texture_buffer_object_rgb32 extension. Textures within ray tracing will be available only when GL_ARB_bindless_texture extension is provided by driver.
On desktop, 3D viewer for optimal performance requires graphics processing unit (GPU) supporting OpenGL 3.3 or above.
Ray tracing requires OpenGL 4.0+ or OpenGL 3.3+ with GL_ARB_texture_buffer_object_rgb32 extension.
Textures within ray tracing will be available only when GL_ARB_bindless_texture extension is provided by driver.
On mobile platforms, OpenGL ES 2.0+ is required for 3D viewer. The ray tracing is not yet available on mobile platforms.
Some old hardware might be unable to execute complex GLSL programs (e.g. with high number of light sources, clipping planes).
The following table lists graphic cards tested to work with OCCT.
| Graphic card | Driver | OS | OpenGL (fixed pipeline) | OpenGL (shaders) | OpenGL (ray tracing) |
| Graphic card | Driver | OS | OpenGL (fixed pipeline) | OpenGL (shaders) | OpenGL (ray tracing) |
| ---- | ---- | ---- | :----: | :----: | :----: |
| NVIDIA GeForce GTX 650 | Driver 340.52, OpenGL 4.4 | Windows 7 64 bit | OK | OK | OK |
| AMD/ATI RadeOn HD 7870 | Driver 14.100, OpenGL 4.4 | Windows 7 64-bit | OK | OK | OK |
| Intel(R) HD Graphics 2500 | Driver 10.18.10.3621, OpenGL 4.0 | Windows 7 64 bit | OK | OK | limited (no textures) |
| RadeOn 9600 | OpenGL 2.1.8454 | Windows XP 32-bit | OK | bad | unsupported by hardware |
| NVIDIA GeForce 6600 GT | OpenGL 2.1 | Windows XP 32-bit | OK | OK | unsupported by hardware |
| NVIDIA GeForce 320 | N/A | Mac OS X 10.6 / OS X 10.10 | OK | OK | not yet supported by OCCT |
| Apple software OpenGL | N/A | Mac OS X 10.6 / OS X 10.10 | OK | OK | N/A |
| Mesa 10.2.4 \* | "Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)" OpenGL 3.0 | Windows 7 64 bit | OK | OK | unsupported by software |
* Mesa implementation of OpenGL is used for certification testing of OCCT
| Mesa 10.2.4 (software emulator) | "Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)" OpenGL 3.0 | Windows 7 64 bit | OK | OK | unsupported by software |
@section OCCT_OVW_SECTION_4 Installation

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 106 KiB

View File

@@ -41,7 +41,7 @@ GENERATE_TREEVIEW = NO
PREDEFINED = PDF_ONLY
GENERATE_LATEX = YES
COMPACT_LATEX = YES
PDF_HYPERLINKS = YES
PDF_HYPERLINKS = NO
USE_PDFLATEX = YES
LATEX_BATCHMODE = YES
LATEX_OUTPUT = latex

View File

@@ -285,10 +285,7 @@ OCAF differs from any other CAD framework in the organization of application dat
OCAF organizes and embeds these attributes in a document. OCAF documents, in their turn, are managed by an OCAF application.
For more details see @ref occt_user_guides__ocaf "OCAF User's Guide" and the OCAF white papers:
* @ref occt_user_guides__ocaf_wp "Application Framework"
* @ref occt_user_guides__ocaf_tree_wp "Distribution of Data through OCAF Tree"
* @ref occt_user_guides__ocaf_functionmechanism_wp "Application Framework Function Mechanism"
For more details see @ref occt_user_guides__ocaf "OCAF User's Guide".
See also: our <a href="http://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.

View File

@@ -232,7 +232,7 @@ The example record is interpreted as a line which passes through a point *P*=(1
**BNF-like Definition**
@verbatim
~~~~
<3D curve record 2> = "2" <_> <3D circle center> <_> <3D circle N> <_> <3D circle Dx> <_> <3D circle Dy> <_> <3D circle radius> <_\n>;
<3D circle center> = <3D point>;
@@ -244,7 +244,7 @@ The example record is interpreted as a line which passes through a point *P*=(1
<3D circle Dy> = <3D direction>;
<3D circle radius> = <real>;
@endverbatim
~~~~
**Description**
@@ -265,7 +265,7 @@ The example record is interpreted as a circle which has its center *P*=(1, 2, 3
**BNF-like Definition**
@verbatim
~~~~
<3D curve record 3> = "3" <_> <3D ellipse center> <_> <3D ellipse N> <_> <3D ellipse Dmaj> <_> <3D ellipse Dmin> <_> <3D ellipse Rmaj> <_> <3D ellipse Rmin> <_\n>;
<3D ellipse center> = <3D point>;
@@ -279,7 +279,7 @@ The example record is interpreted as a circle which has its center *P*=(1, 2, 3
<3D ellipse Rmaj> = <real>;
<3D ellipse Rmin> = <real>;
@endverbatim
~~~~
**Description**
@@ -300,7 +300,7 @@ The example record is interpreted as an ellipse which has its center *P*=(1, 2,
**BNF-like Definition**
@verbatim
~~~~
<3D curve record 4> = "4" <_> <3D parabola origin> <_> <3D parabola N> <_> <3D parabola Dx> <_> <3D parabola Dy> <_> <3D parabola focal length> <_\n>;
<3D parabola origin> = <3D point>;
@@ -312,7 +312,7 @@ The example record is interpreted as an ellipse which has its center *P*=(1, 2,
<3D parabola Dy> = <3D direction>;
<3D parabola focal length> = <real>;
@endverbatim
~~~~
**Description**
@@ -334,7 +334,7 @@ The example record is interpreted as a parabola in plane which passes through a
**BNF-like Definition**
@verbatim
~~~~
<3D curve record 5> = "5" <_> <3D hyperbola origin> <_> <3D hyperbola N> <_> <3D hyperbola Dx> <_> <3D hyperbola Dy> <_> <3D hyperbola Kx> <_> <3D hyperbola Ky> <_\n>;
<3D hyperbola origin> = <3D point>;
@@ -348,7 +348,7 @@ The example record is interpreted as a parabola in plane which passes through a
<3D hyperbola Kx> = <real>;
<3D hyperbola Ky> = <real>;
@endverbatim
~~~~
**Descripton**
@@ -410,7 +410,7 @@ The example record is interpreted as a Bezier curve with a rational flag *r*=1,
**BNF-like Definition**
@verbatim
~~~~
<3D curve record 7> = "7" <_> <3D B-spline rational flag> <_> "0" <_> <3D B-spline degree> <_>
<3D B-spline pole count> <_> <3D B-spline multiplicity knot count> <3D B-spline weight poles>
<_\n> <3D B-spline multiplicity knots> <_\n>;
@@ -430,7 +430,7 @@ The example record is interpreted as a Bezier curve with a rational flag *r*=1,
<3D B-spline multiplicity knots> = (<_> <3D B-spline multiplicity knot>) ^ <3D B-spline multiplicity knot count>;
<3D B-spline multiplicity knot> = <real> <_> <int>;
@endverbatim
~~~~
**Description**
@@ -474,13 +474,13 @@ The example record is interpreted as a B-spline curve with a rational flag *r*=
**BNF-like Definition**
@verbatim
~~~~
<3D curve record 8> = "8" <_> <3D trimmed curve u min> <_> <3D trimmed curve u max> <_\n> <3D curve record>;
<3D trimmed curve u min> = <real>;
<3D trimmed curve u max> = <real>;
@endverbatim
~~~~
**Description**
@@ -746,7 +746,7 @@ where @f$ V(v)=(5,2,0)+4 \cdot (cos(v) \cdot (1,0,0)+sin(v) \cdot (0,1,0)), V_{D
**BNF-like Definition**
@verbatim
~~~~
<surface record 8> = "8" <_> <Bezier surface u rational flag> <_> <Bezier surface v rational flag> <_> <Bezier surface u degree> <_> <Bezier surface v degree> <_>
<Bezier surface weight poles>;
@@ -765,7 +765,7 @@ where @f$ V(v)=(5,2,0)+4 \cdot (cos(v) \cdot (1,0,0)+sin(v) \cdot (0,1,0)), V_{D
(<_> <Bezier surface weight pole>) ^ <Bezier surface v degree>;
<Bezier surface weight pole> = <3D point> [<_> <real>];
@endverbatim
~~~~
**Description**
@@ -781,12 +781,13 @@ where @f$ 0^{0} \equiv 1 @f$.
The example record is interpreted as a Bezier surface with a u rational flag *r<sub>u</sub>*=1, v rational flag *r<sub>v</sub>*=1, u degree *m<sub>u</sub>*=2, v degree *m<sub>v</sub>*=1, weight poles *B<sub>0,0</sub>*=(0, 0, 1), *h<sub>0,0</sub>*=7, *B<sub>0,1</sub>*=(1, 0, -4), *h<sub>0,1</sub>*=10, *B<sub>1,0</sub>*=(0, 1, -2), *h<sub>1,0</sub>*=8, *B<sub>1,1</sub>*=(1, 1, 5), *h<sub>1,1</sub>*=11, *B<sub>2,0</sub>*=(0, 2, 3), *h<sub>2,0</sub>*=9 and *B<sub>2,1</sub>*=(1, 2, 6), *h<sub>2,1</sub>*=12. The surface is defined by the following parametric equation:
@f[ S(u,v)= [ (0,0,1) \cdot 7 \cdot (1-u)^{2} \cdot (1-v)+(1,0,-4) \cdot 10 \cdot (1-u)^{2} \cdot v+ \\
(0,1,-2) \cdot 8 \cdot 2 \cdot u \cdot (1-u) \cdot (1-v)+(1,1,5) \cdot 11 \cdot 2 \cdot u \cdot (1-u) \cdot v+ \\
(0,2,3) \cdot 9 \cdot u^{2} \cdot (1-v)+(1,2,6) \cdot 12 \cdot u^{2} \cdot v] \div \\
[7 \cdot (1-u)^{2} \cdot (1-v)+10 \cdot (1-u)^{2} \cdot v+ \\
8 \cdot 2 \cdot u \cdot (1-u) \cdot (1-v)+11 \cdot 2 \cdot u \cdot (1-u) \cdot v+ \\
9 \cdot u^{2} \cdot (1-v)+12 \cdot u^{2} \cdot v ] @f]
@f[
\begin{align}
S(u,v)= [ (0,0,1) \cdot 7 \cdot (1-u)^{2} \cdot (1-v)+(1,0,-4) \cdot 10 \cdot (1-u)^{2} \cdot v+ (0,1,-2) \cdot 8 \cdot 2 \cdot u \cdot (1-u) \cdot (1-v) + \\
(1,1,5) \cdot 11 \cdot 2 \cdot u \cdot (1-u) \cdot v+ (0,2,3) \cdot 9 \cdot u^{2} \cdot (1-v)+(1,2,6) \cdot 12 \cdot u^{2} \cdot v] \div [7 \cdot (1-u)^{2} \cdot (1-v)+ \\
10 \cdot (1-u)^{2} \cdot v+ 8 \cdot 2 \cdot u \cdot (1-u) \cdot (1-v)+ 11 \cdot 2 \cdot u \cdot (1-u) \cdot v+ 9 \cdot u^{2} \cdot (1-v)+12 \cdot u^{2} \cdot v ]
\end{align}
@f]
@subsubsection occt_brep_format_4_2_9 B-spline Surface - \< surface record 9 \>
@@ -877,14 +878,19 @@ The B-spline surface is defined by the following parametric equation:
where functions *N<sub>i,j</sub>* and *M<sub>i,j</sub>* have the following recursion definition by *j*:
@f[ N_{i,1}(u)=\left\{\begin{matrix}
1\Leftarrow \bar{u}_{i} \leq u \leq \bar{u}_{i+1}\\
0\Leftarrow u < \bar{u}_{i} \vee \bar{u}_{i+1} \leq u \end{matrix} \right.,\;
N_{i,j}(u)=\frac{(u-\bar{u}_{i}) \cdot N_{i,j-1}(u) }{\bar{u}_{i+j-1}-\bar{u}_{i}}+ \frac{(\bar{u}_{i+j}-u) \cdot N_{i+1,j-1}(u)}{\bar{u}_{i+j}-\bar{u}_{i+1}},\;(2 \leq j \leq m_{u}+1); \\
@f[
\begin{align}
N_{i,1}(u)= \left\{\begin{matrix}
1\Leftarrow \bar{u}_{i} \leq u \leq \bar{u}_{i+1}
0\Leftarrow u < \bar{u}_{i} \vee \bar{u}_{i+1} \leq u \end{matrix} \right.,\; \\
N_{i,j}(u)=\frac{(u-\bar{u}_{i}) \cdot N_{i,j-1}(u) }{\bar{u}_{i+j-1}-\bar{u}_{i}}+
\frac{(\bar{u}_{i+j}-u) \cdot N_{i+1,j-1}(u)}{\bar{u}_{i+j}-\bar{u}_{i+1}},\;(2 \leq j \leq m_{u}+1), \; \\
M_{i,1}(v)=\left\{\begin{matrix}
1\Leftarrow \bar{v}_{i} \leq v \leq \bar{v}_{i+1}\\
0\Leftarrow v < \bar{v}_{i} \vee \bar{v}_{i+1} \leq v \end{matrix} \right.,\;
M_{i,j}(v)=\frac{(v-\bar{v}_{i}) \cdot M_{i,j-1}(v) }{\bar{v}_{i+j-1}-\bar{v}_{i}}+ \frac{(\bar{v}_{i+j}-v) \cdot M_{i+1,j-1}(v)}{\bar{v}_{i+j}-\bar{v}_{i+1}},\;(2 \leq j \leq m_{v}+1); @f]
0\Leftarrow v < \bar{v}_{i} \vee \bar{v}_{i+1} \leq v \end{matrix} \right.,\; \\
M_{i,j}(v)=\frac{(v-\bar{v}_{i}) \cdot M_{i,j-1}(v) }{\bar{v}_{i+j-1}-\bar{v}_{i}}+ \frac{(\bar{v}_{i+j}-v) \cdot M_{i+1,j-1}(v)}{\bar{v}_{i+j}-\bar{v}_{i+1}},\;(2 \leq j \leq m_{v}+1);
\end{align}
@f]
where
@f[ \bar{u}_{i}=u_{j}\; (1 \leq j \leq k_{u},\; \sum_{l=1}^{j-1}q_{l} \leq i \leq \sum_{l=1}^{j}q_{l}), \\
@@ -892,13 +898,15 @@ where
The example record is interpreted as a B-spline surface with a u rational flag *r<sub>u</sub>*=1, v rational flag *r<sub>v</sub>*=1, u degree *m<sub>u</sub>*=1, v degree *m<sub>v</sub>*=1, u pole count *n<sub>u</sub>*=3, v pole count *n<sub>v</sub>*=2, u multiplicity knot count *k<sub>u</sub>*=5, v multiplicity knot count *k<sub>v</sub>*=4, weight poles *B<sub>1,1</sub>*=(0, 0, 1), *h<sub>1,1</sub>*=7, *B<sub>1,2</sub>*=(1, 0, -4), *h<sub>1,2</sub>*=10, *B<sub>2,1</sub>*=(0, 1, -2), *h<sub>2,1</sub>*=8, *B<sub>2,2</sub>*=(1, 1, 5), *h<sub>2,2</sub>*=11, *B<sub>3,1</sub>*=(0, 2, 3), *h<sub>3,1</sub>*=9 and *B<sub>3,2</sub>*=(1, 2, 6), *h<sub>3,2</sub>*=12, u multiplicity knots *u<sub>1</sub>*=0, *q<sub>1</sub>*=1, *u<sub>2</sub>*=0.25, *q<sub>2</sub>*=1, *u<sub>3</sub>*=0.5, *q<sub>3</sub>*=1, *u<sub>4</sub>*=0.75, *q<sub>4</sub>*=1 and *u<sub>5</sub>*=1, *q<sub>5</sub>*=1, v multiplicity knots *v<sub>1</sub>*=0, *r<sub>1</sub>*=1, *v<sub>2</sub>*=0.3, *r<sub>2</sub>*=1, *v<sub>3</sub>*=0.7, *r<sub>3</sub>*=1 and *v<sub>4</sub>*=1, *r<sub>4</sub>*=1. The B-spline surface is defined by the following parametric equation:
@f[ S(u,v)= [ (0,0,1) \cdot 7 \cdot N_{1,2}(u) \cdot M_{1,2}(v)+(1,0,-4) \cdot 10 \cdot N_{1,2}(u) \cdot M_{2,2}(v)+ \\
@f[
\begin{align}
S(u,v)= [ (0,0,1) \cdot 7 \cdot N_{1,2}(u) \cdot M_{1,2}(v)+(1,0,-4) \cdot 10 \cdot N_{1,2}(u) \cdot M_{2,2}(v)+ \\
(0,1,-2) \cdot 8 \cdot N_{2,2}(u) \cdot M_{1,2}(v)+(1,1,5) \cdot 11 \cdot N_{2,2}(u) \cdot M_{2,2}(v)+ \\
(0,2,3) \cdot 9 \cdot N_{3,2}(u) \cdot M_{1,2}(v)+(1,2,6) \cdot 12 \cdot N_{3,2}(u) \cdot M_{2,2}(v)] \div \\
[7 \cdot N_{1,2}(u) \cdot M_{1,2}(v)+10 \cdot N_{1,2}(u) \cdot M_{2,2}(v)+ \\
8 \cdot N_{2,2}(u) \cdot M_{1,2}(v)+11 \cdot N_{2,2}(u) \cdot M_{2,2}(v)+ \\
9 \cdot N_{3,2}(u) \cdot M_{1,2}(v)+12 \cdot N_{3,2}(u) \cdot M_{2,2}(v) ] @f]
[7 \cdot N_{1,2}(u) \cdot M_{1,2}(v)+10 \cdot N_{1,2}(u) \cdot M_{2,2}(v)+ 8 \cdot N_{2,2}(u) \cdot M_{1,2}(v)+ \\
11 \cdot N_{2,2}(u) \cdot M_{2,2}(v)+ 9 \cdot N_{3,2}(u) \cdot M_{1,2}(v)+12 \cdot N_{3,2}(u) \cdot M_{2,2}(v) ]
\end{align}
@f]
@subsubsection occt_brep_format_4_2_10 Rectangular Trim Surface - \< surface record 10 \>
@@ -1050,7 +1058,7 @@ The example record is interpreted as a line which passes through a point *P*=(3
**BNF-like Definition**
@verbatim
~~~~
<2D curve record 2> = "2" <_> <2D circle center> <_> <2D circle Dx> <_> <2D circle Dy> <_> <2D circle radius> <_\n>;
<2D circle center> = <2D point>;
@@ -1060,7 +1068,7 @@ The example record is interpreted as a line which passes through a point *P*=(3
<2D circle Dy> = <2D direction>;
<2D circle radius> = <real>;
@endverbatim
~~~~
**Description**
@@ -1221,7 +1229,7 @@ The example record is interpreted as a Bezier curve with a rational flag *r*=1,
**BNF-like Definition**
@verbatim
~~~~
<2D curve record 7> = "7" <_> <2D B-spline rational flag> <_> "0" <_> <2D B-spline degree> <_> <2D B-spline pole count> <_> <2D B-spline multiplicity knot count> <2D B-spline weight poles> <_\n> <2D B-spline multiplicity knots> <_\n>;
<2D B-spline rational flag> = <flag>;
@@ -1240,7 +1248,7 @@ The example record is interpreted as a Bezier curve with a rational flag *r*=1,
<2D B-spline multiplicity knot> ^ <2D B-spline multiplicity knot count>;
<2D B-spline multiplicity knot> = <_> <real> <_> <int>;
@endverbatim
~~~~
**Description**
@@ -1404,7 +1412,7 @@ The example record describes a polyline from *m*=2 nodes with a parameter prese
**BNF-like Definition**
@verbatim
~~~~
<triangulations> = <triangulation header> <_\n> <triangulation records>;
<triangulation header> = "Triangulations" <_> <triangulation count>;
@@ -1434,7 +1442,7 @@ The example record describes a polyline from *m*=2 nodes with a parameter prese
<triangulation triangles> = (<triangulation triangle> <_>) ^ <triangulation triangle count>;
<triangulation triangle> = <int> <_> <int> <_> <int>.
@endverbatim
~~~~
**Description**
@@ -1750,7 +1758,7 @@ The usage of \<vertex data representation u parameter\> *U* is described belo
**BNF-like Definition**
@verbatim
~~~~
<edge data> = <_> <edge data tolerance> <_> <edge data same parameter flag> <_> edge data same range flag> <_> <edge data degenerated flag> <_\n> <edge data representations>;
<edge data tolerance> = <real>;
@@ -1793,7 +1801,7 @@ The usage of \<vertex data representation u parameter\> *U* is described belo
<edge data representation data 7> = (<polygon on triangulation number> <_>) ^ 2
<triangulation number> <_> <location number>;
@endverbatim
~~~~
**Description**
@@ -1820,13 +1828,13 @@ Flags \<edge data same parameter flag\>, \<edge data same range flag\> and \<edg
**BNF-like Definition**
@verbatim
~~~~
<face data> = <face data natural restriction flag> <_> <face data tolerance> <_> <surface number> <_> <location number> <\n> ["2" <_> <triangulation number>];
<face data natural restriction flag> = <flag>;
<face data tolerance> = <real>;
@endverbatim
~~~~
**Description**

View File

@@ -1272,7 +1272,7 @@ When an object is modified or erased, the whole view must be repainted. To avoid
Graphic operations are buffered by Draw (and also by the X system). Usually the buffer is flushed at the end of a command and before graphic selection. If you want to flush the buffer from inside a script, use the **dflush** command.
See also: <a href="#occt_draw_4_1_11">pick</a> command.
See also: @ref occt_draw_4_1_11 "pick" command.
@subsection occt_draw_4_2 AIS viewer view commands
@@ -2970,11 +2970,13 @@ Makes a list of documents handled during the session of the application.
Syntax:
~~~~~
Open path docname
Open path docname [-stream]
~~~~~
Retrieves the document of file **docname** in the path **path**. Overwrites the document, if it is already in session.
option <i>-stream</i> activates usage of alternative interface of OCAF persistence working with C++ streams instead of file names.
**Example:**
~~~~~
Open /myPath/myFile.std D
@@ -3012,10 +3014,12 @@ Save D
Syntax:
~~~~~
SaveAs docname path
SaveAs docname path [-stream]
~~~~~
Saves the active document in the file **docname** in the path **path**. Overwrites the file if it already exists.
Saves the active document in the file **docname** in the path **path**. Overwrites the file if it already exists.
option <i>-stream</i> activates usage of alternative interface of OCAF persistence working with C++ streams instead of file names.
**Example:**
~~~~~
@@ -4234,7 +4238,7 @@ Syntax:
AISMaterial docname entry [material]
~~~~~
Sets (if *material* is defined) or gets the value of transparency for *AISPresentation* attribute of an *entry* label. *material* is integer from 0 to 20 (see <a href="#occt_draw_4_5_6">meshmat</a> command).
Sets (if *material* is defined) or gets the value of transparency for *AISPresentation* attribute of an *entry* label. *material* is integer from 0 to 20 (see @ref occt_draw_4_5_6 "meshmat" command).
**Example:**
~~~~~
@@ -8459,7 +8463,7 @@ These commands are used for translation of IGES and STEP files into an XCAF docu
* XDE layers commands
* XDE propertys commands
Reminding: All operations of translation are performed with parameters managed by command <a href="#occt_draw_8_3_14">the command *param*</a>.
Reminding: All operations of translation are performed with parameters managed by command @ref occt_draw_8_3_14 "param".
@subsubsection occt_draw_8_4_1 ReadIges
@@ -8572,7 +8576,7 @@ Syntax:
XFromShape <shape>
~~~~~
This command is similar to <a href="#occt_draw_8_3_7">the command *fromshape*</a>, but gives additional information about the file name. It is useful if a shape was translated from several files.
This command is similar to the command @ref occt_draw_8_3_7 "fromshape", but gives additional information about the file name. It is useful if a shape was translated from several files.
**Example:**
~~~~~
@@ -9957,14 +9961,14 @@ ADVCURV : TKMyAdvCurv
MESHING : TKMyMesh
~~~~~
For other examples of the plug-in resource file refer to the <a href="#occt_draw_1_3_2">Plug-in resource file</a> chapter above or to the <i>$CASROOT/src/DrawPlugin</i> file shipped with Open CASCADE Technology.
For other examples of the plug-in resource file refer to the @ref occt_draw_1_3_2 "Plug-in resource file" chapter above or to the <i>$CASROOT/src/DrawPlugin</i> file shipped with Open CASCADE Technology.
@subsection occt_draw_11_5 Dynamic loading and activation
Loading a plug-in and activating its commands is described in the <a href="#occt_draw_1_3_3">Activation of the commands implemented in the plug-in</a> chapter.
Loading a plug-in and activating its commands is described in the @ref occt_draw_1_3_3 "Activation of the commands implemented in the plug-in" chapter.
The procedure consists in defining the system variables and using the pload commands in the Test Harness session.
The procedure consists in defining the system variables and using the *pload* commands in the Test Harness session.
**Example:**
~~~~

View File

@@ -811,7 +811,7 @@ void f(1)
Here, the first handler will catch exceptions of *Overflow* type and the second one - exceptions of *NumericError* type and all exceptions derived from it, including *Underflow* and *ZeroDivide*.
The handlers are checked in order of appearance, from the nearest to the most distant try block, until one matches the raise expression. For a try block, it would be a mistake to place a handler for a base exception type ahead of a handler for its derived type since that would ensure that the handler for the derived exception would never be invoked.
The handlers are checked in order of appearance, from the nearest to the try block to the most distant from it, until one matches the raise expression. For a try block, it would be a mistake to place a handler for a base exception type ahead of a handler for its derived type since that would ensure that the handler for the derived exception would never be invoked.
~~~~~
void f(1)

View File

@@ -274,11 +274,6 @@ Default values:
* read.iges.resource.name - IGES,
* read.iges.sequence - FromIGES.
<h4>read.scale.unit</h4>
This parameter is obsolete (the parameter *xstep.cascade.unit* should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
Default value is MM.
<h4>xstep.cascade.unit</h4>
This parameter defines units to which a shape should be converted when translated from IGES or STEP to CASCADE. Normally it is MM; only those applications that work internally in units other than MM should use this parameter.
@@ -816,7 +811,7 @@ Translated objects depend on the write mode that you chose. If you chose the Fa
@subsection occt_iges_3_5 Tolerance management
@subsubsection occt_iges_3_5_1 Setting resolution in an IGES file
There are several possibilities to set resolution in an IGES file. They are controlled by write.precision.mode parameter; the dependence between the value of this parameter and the set resolution is described in paragraph <a href="#occt_iges_3_3_2">Setting the translation parameters</a>.
There are several possibilities to set resolution in an IGES file. They are controlled by write.precision.mode parameter; the dependence between the value of this parameter and the set resolution is described in paragraph @ref occt_iges_3_3_2 "Setting the translation parameters".
If the value of parameter *write.precision.mode* is -1, 0 or 1, resolution is computed from tolerances of sub-shapes inside the shape to be translated. In this computation, only tolerances of *TopoDS_Edges* and *TopoDS_Vertices* participate since they reflect the accuracy of the shape. *TopoDS_Faces* are ignored in computations since their tolerances may have influence on resulting computed resolution while IGES resolution mainly concerns points and curves but not surfaces.
@@ -849,7 +844,7 @@ Standard_Integer main()
~~~~~
@section occt_iges_4_ Using XSTEPDRAW
@section occt_iges_4 Using XSTEPDRAW
XSTEPDRAW UL is intended for creating executables for testing XSTEP interfaces interactively in the DRAW environment. It provides an additional set of DRAW commands specific for the data exchange tasks, which allow loading and writing data files and analysis of resulting data structures and shapes.
@@ -876,7 +871,7 @@ Command *xtrace* is intended to view and change these parameters:
* *Draw xtrace* - directs all messages to the standard output.
@subsection occt_iges_4_3 Reading IGES files
For a description of parameters used in reading an IGES file refer to <a href="#occt_iges_2_3_3">Setting the translation parameters</a>.
For a description of parameters used in reading an IGES file refer to @ref occt_iges_2_3_3 "Setting the translation parameters".
These parameters are set by command *param* :
@@ -893,7 +888,7 @@ Loading is done by the command
~~~~~
Draw> xload <file_name>
~~~~~
Once the file is loaded, it is possible to investigate the structure of the loaded data. To learn how to do it see <a href="#occt_iges_4_4">Analyzing the transferred</a>
Once the file is loaded, it is possible to investigate the structure of the loaded data. To learn how to do it see @ref occt_iges_4_4 "Analyzing the transferred".
Reading of an IGES file is done by the command
~~~~~
@@ -915,7 +910,7 @@ After the selected set of entities is loaded the user will be asked how loaded
The second parameter of the *igesbrep* command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter is s, they will be <i>s_1, ... s_N.</i>
<i>\<selection\></i> specifies the scope of selected entities in the model, it is *xst-transferrable-roots* by default. An asterisk “*” can be specified instead of *iges-visible-transf-roots*. For possible values of *selection* refer to <a href="#occt_iges_2_3_4">Selecting entities</a> section.
<i>\<selection\></i> specifies the scope of selected entities in the model, it is *xst-transferrable-roots* by default. An asterisk “*” can be specified instead of *iges-visible-transf-roots*. For possible values of *selection* refer to @ref occt_iges_2_3_4 "Selecting entities" section.
Instead of *igesbrep* it is possible to use commands:
@@ -1095,7 +1090,7 @@ When specifying *min* and *max* arguments this command outputs shapes with name
@subsection occt_iges_4_5 Writing an IGES file
Refer to <a href="#occt_iges_3_3_2">Setting the translation parameters</a> for a description of parameters used in reading an IGES file. The parameters are set by command *param*:
Refer to @ref occt_iges_3_3_2 "Setting the translation parameters" for a description of parameters used in reading an IGES file. The parameters are set by command *param*:
| Description | Name | Values |
| :----------- | :---- | :----- |
@@ -1134,10 +1129,10 @@ Loading the file only memorizes, but does not translate the data.
@subsection occt_iges_5_2 Checking the loaded IGES file
This step is not obligatory. See the description of this step <a href="#occt_iges_2_3_2"> above</a>.
This step is not obligatory. See the description of @ref occt_iges_2_3_2 "Checking the IGES file" above.
@subsection occt_iges_5_3 Setting parameters for translation to XDE
See the description of this step <a href="#occt_iges_2_3_3"> above</a>.
See the description of @ref occt_iges_2_3_3 "Setting translation parameters" above.
In addition, the following parameters can be set for XDE translation of attributes:
* For transferring colors:

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.6 KiB

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 102 KiB

After

Width:  |  Height:  |  Size: 82 KiB

View File

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

View File

Before

Width:  |  Height:  |  Size: 35 KiB

After

Width:  |  Height:  |  Size: 35 KiB

View File

Before

Width:  |  Height:  |  Size: 42 KiB

After

Width:  |  Height:  |  Size: 42 KiB

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

File diff suppressed because it is too large Load Diff

View File

@@ -1,286 +0,0 @@
OCAF Function Mechanism {#occt_user_guides__ocaf_functionmechanism_wp}
========================
@tableofcontents
@section occt_ocaf_functionmechanism_wp_1 Introduction
This guide describes the usage of the Function Mechanism of Open CASCADE Application Framework on a simple example.
This example represents a "nail" composed by a cone and two cylinders of different radius and height:
@image html ocaf_functionmechanism_wp_image003.png "A nail"
@image latex ocaf_functionmechanism_wp_image003.png " A nail"
These three objects (a cone and two cylinders) are independent,
but the Function Mechanism makes them connected to each other and representing one object a nail.
The object "nail" has the following parameters:
* The position of the nail is defined by the apex point of the cone.
The cylinders are built on the cone and therefore they depend on the position of the cone.
In this way we define a dependency of the cylinders on the cone.
* The height of the nail is defined by the height of the cone.
Lets consider that the long cylinder has 3 heights of the cone
and the header cylinder has a half of the height of the cone.
* The radius of the nail is defined by the radius of the cone.
The radius of the long cylinder coincides with this value.
Lets consider that the header cylinder has one and a half radiuses of the cone.
So, the cylinders depend on the cone and the cone parameters define the size of the nail.
It means that re-positioning the cone (changing its apex point) moves the nail,
the change of the radius of the cone produces a thinner or thicker nail,
and the change of the height of the cone shortens or prolongates the nail.
 It is suggested to examine the programming steps needed to create a 3D parametric model of the "nail".
This guide describes in detail usage of the Function Mechanism.
Other aspects, such as the data model and the interfaces are mentioned in brief.
@section occt_ocaf_functionmechanism_wp_2 Step 1: Data Tree
The first step consists in model data allocation in the OCAF tree.
In other words, it is necessary to decide where to put the data.
In this case, the data can be organized into a simple tree
using references for definition of dependent parameters:
* Nail
* Cone
+ Position (x,y,z)
+ Radius
+ Height
* Cylinder (stem)
+ Position = "Cone" position translated for "Cone" height along Z;
+ Radius = "Cone" radius;
+ Height = "Cone" height multiplied by 3;
* Cylinder (head)
+ Position = "Long cylinder" position translated for "Long cylinder" height along Z;
+ Radius = "Long cylinder" radius multiplied by 1.5;
+ Height = "Cone" height divided by 2.
The "nail" object has three sub-leaves in the tree: the cone and two cylinders.
The cone object is independent.
The long cylinder representing a "stem" of the nail refers to the corresponding parameters
of the cone to define its own data (position, radius and height). It means that the long cylinder depends on the cone.
The parameters of the head cylinder may be expressed through the cone parameters
only or through the cone and the long cylinder parameters.
It is suggested to express the position and the radius of the head cylinder
through the position and the radius of the long cylinder, and the height
of the head cylinder through the height of the cone.
It means that the head cylinder depends on the cone and the long cylinder.
@section occt_ocaf_functionmechanism_wp_3 Step 2: Interfaces
The interfaces of the data model are responsible for dynamic creation
of the data tree of the represented at the previous step, data modification and deletion.
The interface called *INail* should contain the methods for creation
of the data tree for the nail, setting and getting of its parameters, computation, visualization and removal.
@subsection occt_ocaf_functionmechanism_wp_3_1 Creation of the nail
This method of the interface creates a data tree for the nail at a given leaf of OCAF data tree.
It creates three sub-leaves for the cone and two cylinders and allocates the necessary data (references at the sub-leaves of the long and the head cylinders).
It sets the default values of position, radius and height of the nail.
The nail has the following user parameters:
* The position coincides with the position of the cone
* The radius of the stem part of the nail coincides with the radius of the cone
* The height of the nail a sum of heights of the cone and both cylinders
The values of the position and the radius of the nail are defined for the cone object data.
The height of the cone is recomputed as 2 * heights of nail and divided by 9.
@subsection occt_ocaf_functionmechanism_wp_3_2 Computation
The Function Mechanism is responsible for re-computation of the nail.
It will be described in detail later in this document.
A data leaf consists of the reference  to the location of the real data
and a real value defining a coefficient of multiplication of the referenced data.
For example, the height of the long cylinder is defined as a reference to the height of the cone
with coefficient 3. The data leaf of the height of the long cylinder
should contain two attributes: a reference to the height of cone and a real value equal to 3.
@subsection occt_ocaf_functionmechanism_wp_3_3 Visualization
 The shape resulting of the nail function can be displayed using the standard OCAF visualization mechanism.
@subsection occt_ocaf_functionmechanism_wp_3_4 Removal of the nail
To automatically erase the nail from the viewer and the data tree it is enough to clean the nail leaf from attributes.
@section occt_ocaf_functionmechanism_wp_4 Step 3: Functions
The nail is defined by four functions: the cone, the two cylinders and the nail function.
The function of the cone is independent. The functions of the cylinders depend on the cone function.
The nail function depends on the results of all functions:
@image html ocaf_functionmechanism_wp_image005.png "Picture 3. A graph of dependencies between functions"
@image latex ocaf_functionmechanism_wp_image005.png "Picture 3. A graph of dependencies between functions"
Computation of the model starts with the cone function, then the long cylinder,
after that the header cylinder and, finally, the result is generated by the nail function at the end of function chain.
The Function Mechanism of Open CASCADE Technology creates this graph of dependencies
and allows iterating it following the dependencies.
The only thing the Function Mechanism requires from its user
is the implementation of pure virtual methods of *TFunction_Driver*:
* <i>\::Arguments()</i> returns a list of arguments for the function
* <i>\::Results()</i> returns a list of results of the function
These methods give the Function Mechanism the information on the location of arguments
and results of the function and allow building a graph of functions.
The class *TFunction_Iterator* iterates the functions of the graph in the execution order.
The pure virtual method *TFunction_Driver::Execute()* calculating the function should be overridden.
The method <i>\::MustExecute()</i> calls the method <i>\::Arguments()</i> of the function driver
and ideally this information (knowledge of modification of arguments of the function) is enough
to make a decision whether the function should be executed or not. Therefore, this method usually shouldnt be overridden.
The cone and cylinder functions differ only in geometrical construction algorithms.
Other parameters are the same (position, radius and height).
It means that it is possible to create a base class function driver for the three functions,
and two descendent classes producing: a cone or a cylinder.
For the base function driver the methods <i>\::Arguments()</i> and <i>\::Results()</i> will be overridden.
Two descendent function drivers responsible for creation of a cone and a cylinder will override only the method <i>\::Execute()</i>.
The method <i>\::Arguments()</i> of the function driver of the nail returns the results of the functions located under it in the tree of leaves. The method <i>\::Execute()</i> just collects the results of the functions and makes one shape a nail.
This way the data model using the Function Mechanism is ready for usage. Do not forget to introduce the function drivers for a function driver table with the help of *TFunction_DriverTable* class.
@section occt_ocaf_functionmechanism_wp_5 Appendix 1
This appendix gives an example of the code for iteration and execution of functions.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
// The scope of functions is defined.
Handle(TFunction_Scope) scope = TFunction_Scope::Set( anyLabel );
// The information on modifications in the model is received.
TFunction_Logbook&amp; log = scope-GetLogbook();
// The iterator is iInitialized by the scope of functions.
TFunction_Iterator iterator( anyLabel );
Iterator.SetUsageOfExecutionOrder( true );
// The function is iterated,  its dependency is checked on the modified data and  executed if necessary.
for (; iterator.more(); iterator.Next())
{
// The function iterator may return a list of current functions for execution.
// It might be useful for multi-threaded execution of functions.
const TDF_LabelList&amp; currentFunctions = iterator.Current();
//The list of current functions is iterated.
TDF_ListIteratorOfLabelList currentterator( currentFucntions );
for (; currentIterator.More(); currentIterator.Next())
{
// An interface for the function is created.
TFunction_IFunction interface( currentIterator.Value() );
// The function driver is retrieved.
Handle(TFunction_Driver) driver = interface.GetDriver();
// The dependency of the function on the  modified data is checked.
If (driver-MustExecute( log ))
{
// The function is executed.
int ret = driver-Execute( log );
if ( ret )
return false;
} // end if check on modification
} // end of iteration of current functions
} // end of iteration of functions.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@section occt_ocaf_functionmechanism_wp_6 Appendix 2
This appendix gives an example of the code for a cylinder function driver. In order to make the things clearer, the methods <i>\::Arguments()</i> and <i>\::Results()</i> from the base class are also mentioned.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
// A virtual method ::Arguments() returns a list of arguments of the function.
CylinderDriver::Arguments( TDF_LabelList&amp; args )
{
// The direct arguments, located at sub-leaves of the fucntion, are collected (see picture 2).
TDF_ChildIterator cIterator( Label(), false );
for (; cIterator.More(); cIterator.Next() )
{
// Direct argument.
TDF_Label sublabel = cIterator.Value();
Args.Append( sublabel );
// The references to the external data are checked.
Handle(TDF_Reference) ref;
If ( sublabel.FindAttribute( TDF_Reference::GetID(), ref ) )
{
args.Append( ref-Get() );
}
}
// A virtual method ::Results() returns a list of result leaves.
CylinderDriver::Results( TDF_LabelList&amp; res )
{
// The result is kept at the function label.
  Res.Append( Label() );
}
// Execution of the function driver.
Int CylinderDriver::Execute( TFunction_Logbook&amp; log )
{
// Position of the cylinder position of the first function (cone)
//is  elevated along Z for height values of all previous functions.
gp_Ax2 axes = …. // out of the scope of this guide.
// The radius value is retrieved.
// It is located at second child sub-leaf (see the picture 2).
TDF_Label radiusLabel = Label().FindChild( 2 );
// The multiplicator of the radius ()is retrieved.
Handle(TDataStd_Real) radiusValue;
radiusLabel.FindAttribute( TDataStd_Real::GetID(), radiusValue);
// The reference to the radius is retrieved.
Handle(TDF_Reference) refRadius;
RadiusLabel.FindAttribute( TDF_Reference::GetID(), refRadius );
// The radius value is calculated.
double radius = 0.0;
if ( refRadius.IsNull() )
{
radius = radiusValue-Get();
}
else
{
// The referenced radius value is retrieved.
Handle(TDataStd_Real) referencedRadiusValue;
RefRadius-Get().FindAttribute(TDataStd_Real::GetID() ,referencedRadiusValue );
radius = referencedRadiusValue-Get() * radiusValue-Get();
}
// The height value is retrieved.
double height = … // similar code to taking the radius value.
// The cylinder is created.
TopoDS_Shape cylinder = BRepPrimAPI_MakeCylinder(axes, radius, height);
// The result (cylinder) is set
TNaming_Builder builder( Label() );
Builder.Generated( cylinder );
// The modification of the result leaf is saved in the log.
log.SetImpacted( Label() );
return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@@ -1,139 +0,0 @@
Distribution of Data Through OCAF Tree {#occt_user_guides__ocaf_tree_wp}
=======================================
@tableofcontents
@section occt_ocaf_tree_wp_1 Introduction
Open CASCADE Application Framework (OCAF) represents a set of classes for Rapid Application Development.
OCAF helps to implement such functions as undo and redo, copy, cut and paste, storage and retrieval of documents, and many others.
OCAF is based on a notion of label-attribute. The labels form a tree.
The attributes are attached to the labels and store user data in the OCAF document.
This document describes how data should be stored in the OCAF document and considers the following issues:
* Should we choose standard attributes or is it better to create new ones?
* How can we optimize data allocation to make it easy to use and efficient for memory usage and application speed?
In particular, the document describes an example of using standard OCAF attributes and creating new OCAF attributes. It is assumed that the reader is already familiar with some OCAF basics.
@section occt_ocaf_tree_wp_2 Description
When you start to design an application based on OCAF,
usually you need to choose between standard and newly-created attributes
to be used for allocation of data in the OCAF document.
Before giving an answer to this question, lets overview standard OCAF attributes.
All basic data types are represented in OCAF as special attributes:
* Integer,
* Double,
* String,
* Array of integer values,
* Array of double values,
* Array of string values,
* Topological shapes.
An attentive reader might have noticed that there is no Boolean type.
This is because the Integer type is usually used instead.
So, we have an opportunity to describe any model by means of standard OCAF attributes.
But will this description be efficient for memory, speed, and, at the same time, convenient to use?
It depends on a particular model.
OCAF has one restriction: only one attribute type may be allocated to one label.
It is necessary to take into account the design of the application data tree.
For example, if a label should possess several double values,
it is necessary to distribute them through several child sub-labels or use an array of double values.
Lets consider several boundary implementations of the same model in OCAF tree
and analyse the advantages and disadvantages of each approach.
@section occt_ocaf_tree_wp_3 Comparison and analysis of approaches
Below are described two different model implementations:
one is based on standard OCAF attributes and the other is based
on the creation of a new attribute possessing all data of the model.
A load is distributed through the shape. The measurements are taken at particular points defined by (x, y and z) co-ordinates. The load is represented as a projection onto X, Y and Z axes of the local co-ordinate system at each point of measurement. A matrix of transformation is needed
to convert the local co-ordinate system to the global one, but this is optional.
So, we have 15 double values at each point of measurement.
If the number of such points is 100 000, for example, it means
that we have to store 1 500 000 double values in the OCAF document.
The first approach consists in using standard OCAF attributes.
Besides, there are several variants of how the standard attributes may be used:
* Allocation of all 1 500 000 double values as one array of double values attached to one label;
* Allocation of values of one measure of load (15 values) as one array of double values and attachment of one point of measure to one label;
* Allocation of each point of measure as an array of 3 double values attached to one label, the projection of load onto the local co-ordinate system axes as another array of 3 double values attached to a sub-label, and the matrix of projection (9 values) as the third array also attached to a sub-label.
Certainly, other variants are also possible.
@image html ocaf_tree_wp_image003.png "Allocation of all data as one array of double values"
@image latex ocaf_tree_wp_image003.png "Allocation of all data as one array of double values"
The first approach to allocation of all data represented as one array of double values
saves initial memory and is easy to implement.
But access to the data is difficult because the values are stored in a flat array.
It will be necessary to implement a class with several methods giving access
to particular fields like the measurement points, loads and so on.
If the values may be edited in the application,
it means that the whole array will be backed-up on each edition.
The memory usage will increase very fast!
So, this approach may be considered only in case of non-editable data.
Lets consider the allocation of data of each measurement point per label (the second case).
In this case we create 100 000 labels one label for each measurement point
and attach an array of double values to these labels:
@image html ocaf_tree_wp_image004.png "Allocation of data of each measurement point as arrays of double values"
@image latex ocaf_tree_wp_image004.png "Allocation of data of each measurement point as arrays of double values"
Now edition of data is safer as far as memory usage is concerned.
Change of value for one measurement point (any value: point co-ordinates, load, and so on)
backs-up only one small array of double values.
But this structure (tree) requires more memory space (additional labels and attributes).
Besides, access to the values is still difficult and it is necessary
to have a class with methods of access to the array fields.
The third case of allocation of data through OCAF tree is represented below:
@image html ocaf_tree_wp_image005.png "Allocation of data into separate arrays of double values"
@image latex ocaf_tree_wp_image005.png "Allocation of data into separate arrays of double values"
In this case sub-labels are involved and we can easily access the values of each measurement point,
load or matrix. We dont need an interface class with methods of access to the data
(if it exists, it would help to use the data structure, but this is optional).
On the one hand, this approach requires more memory for allocation of the attributes (arrays of double values).
On the other hand, it saves memory during the edition of data
by backing-up only the small array containing the modified data.
So, if the data is fully modifiable, this approach is more preferable.
Before making a conclusion, lets consider the same model implemented through a newly created OCAF attribute.
For example, we might allocate all data belonging to one measurement point as one OCAF attribute.
In this case we implement the third variant of using the standard attributes (see picture 3),
but we use less memory (because we use only one attribute instead of three):
@image html ocaf_tree_wp_image006.png "Allocation of data into newly created OCAF attribute"
@image latex ocaf_tree_wp_image006.png "Allocation of data into newly created OCAF attribute"
The second variant of using standard OCAF attributes still has drawbacks:
when data is edited, OCAF backs-up all values of the measurement point.
Lets imagine that we have some non-editable data.
It would be better for us to allocate this data separately from editable data.
Back-up will not affect non-editable data and memory will not increase so much during data edition.
@section occt_ocaf_tree_wp_4 Conclusion
When deciding which variant of data model implementation to choose,
it is necessary to take into account the application response time,
memory allocation and memory usage in transactions.
Most of the models may be implemented using only standard OCAF attributes.
Some other models need special treatment and require implementation of new OCAF attributes.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 35 KiB

View File

@@ -1,621 +0,0 @@
OCAF White-Paper {#occt_user_guides__ocaf_wp}
========================
@tableofcontents
@section ocaf_wp_1 What is OCAF ?
@subsection ocaf_wp_1_1 Purpose of OCAF
The Open CASCADE Application Framework (OCAF) is an easy-to-use platform for rapidly developing
sophisticated domain-specific design applications.
A typical application developed using OCAF deals with two or three-dimensional (2D or 3D) geometric modeling
in trade-specific Computer Aided Design (CAD) systems, manufacturing or analysis applications,
simulation applications or illustration tools.
Developing a design application requires addressing many technical aspects.
In particular, given the functional specification of your application, you must at least:
* Design the architecture of the application — definition of the software components and the way they cooperate
* Define the data model able to support the functionality required — a design application operates on data maintained during the whole end-user working session
* Structure the software in order to
* synchronize the display with the data — commands modifying objects must update the views
* support generalized undo-redo commands — this feature has to be taken into account very early in the design process
* Implement the function for saving the data — if the application has a long life cycle, the compatibility of data between versions of the application has to be addressed
* Build the application user interface
By providing architectural guidance and ready-to-use solutions to these issues,
OCAF helps you to develop your application significantly faster: you concentrate on the application's functionality.
As you use the architecture provided by OCAF, the design of your application is made easy: as the application developer you can concentrate on the functionality instead of the underlying mechanisms required to support it.
Also, thanks to the coupling with the other Open CASCADE Technology modules,
your application can rapidly be prototyped. In addition, the final application
can be developed by industrializing the prototype — you don't need to restart the development from scratch.
Last but not least, you base your application on an Open Source component:
this guarantees the long-term usefulness of your development.
@subsection ocaf_wp_1_2 Overview of the Architecture
OCAF provides you with an object-oriented Application-Document-Attribute model.
This consists of C++ class libraries. The main class, Application, is an abstract class
in charge of handling documents during the working session. Services provided by this class include:
* Creating new documents
* Saving documents and opening them
* Initializing document views
The document, implemented by the concrete class Document, is the container for the application data.
Its main purpose is to centralize notifications of data editing in order to provide Undo-Redo.
Each document is saved in a single flat ASCII file defined by its format and extension (a ready-to-use format is provided with OCAF).
Application data are attributes, that is, instances of classes derived from the *Attribute* abstract class,
organized according to the OCAF Data Framework.
The OCAF Data Framework references aggregations of attributes using persistent identifiers in a single hierarchy (the Data Framework is described <a href="#ocaf_wp_2">in the next chapter</a>). A wide range of attributes come with OCAF, including:
* Primitive attributes such as *Integer, Real, Name* and *Comment*;
* Shape attribute containing the geometry of the whole model or elements of it;
* Other geometric attributes such as Datums (points, axis and plane) and Constraints (*tangent-to, at-a-given-distance, from-a-given-angle, concentric,* etc.)
* Modeling step and Function attributes — the purpose of these attributes is to rebuild objects after they have been modified (parameterization of models)
* Visualization attributes — these attributes allow data to be visualized in a 2D or 3D viewer
* User attributes, that is, attributes typed by the application
* In addition, application-specific data can be added by defining new attribute classes;
naturally, this changes the standard file format. The only functions that have to be implemented are:
* Copying the attribute
* Converting it from and to its persistent homolog (persistence is briefly presented in the paragraph <a href="#ocaf_wp_2_3">Persistent Data Storage</a>)
@image html ocaf_wp_image003.png "The Application-Document-Attribute model "
@image latex ocaf_wp_image003.png "The Application-Document-Attribute model "
OCAF uses other modules of Open CASCADE Technology — the Shape attribute is implemented with the geometry supported by the <a href="#user_guides__modeling_data">Modeling Data</a> module and the viewer is the one provided with the <a href="#user_guides__visualization">Visualization</a> module. Modeling functions can be implemented using the <a href="#user_guides__modeling_algos">Modeling Algorithms</a> module.
@subsection ocaf_wp_1_3 Getting Started
At the beginning of your development, you first define an application class by inheriting from the Application abstract class.
You only have to create and determine the resources of the application
for specifying the format of your documents (you generally use the standard one) and their file extension.
Then, you design the application data model by organizing attributes you choose among those provided with OCAF.
You can specialize these attributes using the User attribute. For example, if you need a reflection coefficient,
you aggregate a User attribute identified as a reflection coefficient
with a Real attribute containing the value of the coefficient (as such, you don't define a new class).
If you need application specific data not provided with OCAF, for example,
to incorporate a finite element model in the data structure,
you define a new attribute class containing the mesh,
and you include its persistent homologue in a new file format.
Once you have implemented the commands which create and modify the data structure
according to your specification, OCAF provides you, without any additional programming:
* Persistent reference to any data, including geometric elements — several documents can be linked with such reference;
* Document-View association;
* Ready-to-use functions such as :
* Undo-redo;
* Save and open application data.
Finally, you develop the application's graphical user interface using the toolkit of your choice, for example:
* KDE Qt or GNOME GTK+ on Linux;
* Microsoft Foundation Classes (MFC) on Windows Motif on Sun;
* Other commercial products such as Ilog Views.
You can also implement the user interface in the Java language using
the Swing-based Java Application Desktop component (JAD) provided with OCAF.
@subsection ocaf_wp_1_4 An example of OCAF usage
To create a useful OCAF-based application, it is necessary to redefine two deferred methods: <i> Formats</i> and <i> ResourcesName</i>
In the <i> Formats </i> method, add the format of the documents, which need to be read by the application and may have been built in other applications.
For example:
~~~~
void myApplication::Formats(TColStd_SequenceOfExtendedString& Formats)
{
Formats.Append(TCollection_ExtendedString ("OCAF-myApplication"));
}
~~~~
In the <i> ResourcesName</i> method, you only define the name of the resource file. This
file contains several definitions for the saving and opening mechanisms associated
with each format and calling of the plug-in file.
~~~~
Standard_CString myApplication::ResourcesName()
{
return Standard_CString ("Resources");
}
~~~~
To obtain the saving and opening mechanisms, it is necessary to set two environment variables: <i> CSF_PluginDefaults</i>, which defines the path of the plug-in file, and <i> CSF_ResourcesDefault</i>, which defines the resource file:
~~~~
SetEnvironmentVariable ( "CSF_ResourcesDefaults",myDirectory);
SetEnvironmentVariable ( "CSF_PluginDefaults",myDirectory);
~~~~
The plugin and the resource files of the application will be located in <i> myDirector</i>.
The name of the plugin file must be <i>Plugin</i>.
### Resource File
The resource file describes the documents (type and extension) and
the type of data that the application can manipulate
by identifying the storage and retrieval drivers appropriate for this data.
Each driver is unique and identified by a GUID generated, for example, with the <i> uuidgen </i> tool in Windows.
Five drivers are required to use all standard attributes provided within OCAF:
* the schema driver (ad696002-5b34-11d1-b5ba-00a0c9064368)
* the document storage driver (ad696000-5b34-11d1-b5ba-00a0c9064368)
* the document retrieval driver (ad696001-5b34-11d1-b5ba-00a0c9064368)
* the attribute storage driver (47b0b826-d931-11d1-b5da-00a0c9064368)
* the attribute retrieval driver (47b0b827-d931-11d1-b5da-00a0c9064368)
These drivers are provided as plug-ins and are located in the <i> PappStdPlugin</i> library.
For example, this is a resource file, which declares a new model document OCAF-MyApplication:
~~~~
formatlist:OCAF-MyApplication
OCAF-MyApplication.Description: MyApplication Document Version 1.0
OCAF-MyApplication.FileExtension: sta
OCAF-MyApplication.StoragePlugin: ad696000-5b34-11d1-b5ba-00a0c9064368
OCAF-MyApplication.RetrievalPlugin: ad696001-5b34-11d1-b5ba-00a0c9064368
OCAF-MyApplicationSchema: ad696002-5b34-11d1-b5ba-00a0c9064368
OCAF-MyApplication.AttributeStoragePlugin: 47b0b826-d931-11d1-b5da-00a0c9064368
OCAF-MyApplication.AttributeRetrievalPlugin: 47b0b827-d931-11d1-b5da-00a0c9064368
~~~~
### Plugin File
The plugin file describes the list of required plug-ins to run the application and the
libraries in which plug-ins are located.
You need at least the <i> FWOSPlugin</i> and the plug-in drivers to run an OCAF application.
The syntax of each item is <i> Identification.Location Library_Name, </i> where:
* Identification is GUID.
* Location defines the location of the Identification (where its definition is found).
* Library_Name is the name (and path to) the library, where the plug-in is located.
For example, this is a Plugin file:
~~~~
a148e300-5740-11d1-a904-080036aaa103.Location: FWOSPlugin
! base document drivers plugin
ad696000-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
ad696001-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
ad696002-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
47b0b826-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin
47b0b827-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin
~~~~
@section ocaf_wp_2 A Look Inside OCAF
@subsection ocaf_wp_2_1 The Design of OCAF
@subsubsection ocaf_wp_2_1_1 Reference-key model
In most existing geometric modeling systems, the data are topology driven.
They usually use a boundary representation (BRep), where geometric models
are defined by a collection of faces, edges and vertices,
to which application data are attached. Examples of data include:
* a color;
* a material;
* information that a particular edge is blended.
When the geometric model is parameterized, that is, when you can change
the value of parameters used to build the model (the radius of a blend, the thickness of a rib, etc.),
the geometry is highly subject to change.
In order to maintain the attachment of application data, the geometry must be distinguished from other data.
In OCAF, the data are reference-key driven. It is a uniform model in which reference-keys
are the persistent identification of data. All **accessible** data, including the geometry,
are implemented as attributes attached to reference-keys.
The geometry becomes the value of the Shape attribute, just as a number is the value
of the Integer and Real attributes and a string that of the Name attribute.
On a single reference-key, many attributes can be aggregated;
the application can ask at runtime which attributes are available.
For example, to associate a texture to a face in a geometric model,
both the face and the texture are attached to the same reference-key.
@image html ocaf_wp_image004.png "Figure 2. Topology driven versus reference-key driven approaches"
@image latex ocaf_wp_image004.png "Figure 2. Topology driven versus reference-key driven approaches"
@subsubsection ocaf_wp_2_1_2 Topological naming
Reference-keys can be created in two ways:
* At programming time, by the application
* At runtime, by the end-user of the application (providing that you include this capability in the application)
As an application developer, you generate reference-keys in order to give semantics to the data.
For example, a function building a prism may create three reference-keys:
one for the base of the prism, a second for the lateral faces and a third for the top face.
This makes up a semantic built-in the application's prism feature.
On the other hand, in a command allowing the end-user to set a texture to a face he/she selects,
you must create a reference-key to the selected face
if it has not previously been referenced in any feature
(as in the case of one of the lateral faces of the prism).
When you create a reference-key to selected topological elements (faces, edges or vertices),
OCAF attaches to the reference-key information defining the selected topology — the Naming attribute.
For example, it may be the faces to which a selected edge is common to.
This information, as well as information about the evolution of the topology at each modeling step
(the modified, updated and deleted faces), is used by the naming algorithm to maintain the topology
attached to the reference-key. As such, on a parametrized model,
after modifying the value of a parameter, the reference-keys still address the appropriate faces,
even if their geometry has changed.
Consequently, you change the size of the cube shown in the figure 2 above,
the user texture stay attached to the right face.
<b>Note</b> As Topological naming is based on the reference-key and attributes such as Naming
(selection information) and Shape (topology evolution information),
OCAF is not coupled to the underlying modeling libraries.
The only modeling services required by OCAF are the following:
* Each algorithm must provide information about the evolution of the topology
(the list of faces modified, updated and deleted by the algorithm)
* Exploration of the geometric model must be available
(a 3D model is made of faces bounded by close wires,
themselves composed by a sequence of edges connected by their vertices)
Currently, OCAF uses the Open CASCADE Technology modeling libraries.
@subsubsection ocaf_wp_2_1_3 Aggregation of attributes
To design an OCAF-based data model, the application developer is encouraged to aggregate
ready-to-use attributes instead of defining new attributes by inheriting from an abstract root class.
There are two major advantages in using aggregation rather than inheritance:
* As you don't implement data by defining new classes, the format of saved data
provided with OCAF doesn't change; so you don't have to write the Save and Open functions
* The application can query the data at runtime if a particular attribute is available
@subsubsection ocaf_wp_2_1_4 Summary
* OCAF is based on a uniform reference-key model in which:
* Reference-keys provide persistent identification of data;
* Data, including geometry, are implemented as attributes attached to reference-keys;
* Topological naming maintains the selected geometry attached to reference-keys in parametrized models ;
* In many applications, the data format provided with OCAF doesn't need to be extended;
* OCAF is not coupled to the underlying modeling libraries.
@subsection ocaf_wp_2_2 The Data Framework
@subsubsection ocaf_wp_2_2_1 Data structure
The OCAF Data Framework is the Open CASCADE Technology realization
of the reference-key model presented in the previous paragraph.
It implements the reference-key as label objects,
organized in a tree structure characterized by the following features:
* A document contains only one tree of labels
* Each label has a tag expressed as an integer value unique at its level in the tree
* A label is identified by a string — the entry — built by concatenation of tags from the root of the tree, for example [0:1:2:1]
* Attributes are of a type identified by a universal unique identifier (GUID)
* Attributes are attached to labels; a label may refer to many attributes as long as each has a different GUID
As such, each piece of data has a unique persistent address made up of the document path,
its entry and the GUID of its class.
In the image the application for designing coffee machines first allocates
a label for the machine unit. It then adds sub-labels for the main features
(glass coffee pot, water receptacle and filter) which it refines as needed
(handle and reservoir of the coffee pot and spout of the reservoir).
You now attach technical data describing the handle — its geometry and color —
and the reservoir — its geometry and material.
Later on, you can modify the handle's geometry without changing its color —
both remain attached to the same label.
@image html ocaf_wp_image005.png "Figure 3. The data structure of the coffee machine"
@image latex ocaf_wp_image005.png "Figure 3. The data structure of the coffee machine"
The nesting of labels is key to OCAF. This allows a label to have its own structure
with its local addressing scheme which can be reused in a more complex structure.
Take, for example, the coffee machine. Given that the coffee pot's handle has a label of tag [1],
the entry for the handle in the context of the coffee pot only (without the machine unit) is [0:1:1].
If you now model a coffee machine with two coffee pots, one at the label [1],
the second at the label [4] in the machine unit,
the handle of the first pot would have the entry [0:1:1:1]
whereas the handle of the second pot would be [0:1:4:1].
This way, we avoid any confusion between coffee pot handles.
@subsubsection ocaf_wp_2_2_2 Compound documents
As the identification of data is persistent, one document can reference data contained in another document,
the referencing and referenced documents being saved in two separate files.
Lets look at the coffee machine application again. The coffee pot can be placed in one document.
The coffee machine document then includes an *occurrence* — a positioned copy — of the coffee pot.
This occurrence is defined by an XLink attribute (the external Link)
which references the coffee pot of the first document
(the XLink contains the relative path of the coffee pot document and the entry of the coffee pot data [0:1] ).
@image html ocaf_wp_image006.png "The coffee machine compound document"
@image latex ocaf_wp_image006.png "The coffee machine compound document"
In this context, the end-user of the coffee machine application can open the coffee pot document,
modify the geometry of, for example, the reservoir, and overwrite the document without worrying
about the impact of the modification in the coffee machine document.
To deal with this situation, OCAF provides a service which allows the application to check
whether a document is up-to-date. This service is based on a modification counter included in each document:
when an external link is created, a copy of the referenced document counter is associated to the XLink
in the referencing document. Providing that each modification of the referenced document increments its own counter,
we can detect that the referencing document has to be updated by comparing the two counters
(an update function importing the data referenced by an XLink into the referencing document is also provided).
@subsubsection ocaf_wp_2_2_3 Transaction mechanism
The Data Framework also provides a transaction mechanism inspired from database management systems:
the data are modified within a transaction which is terminated either by a Commit
if the modifications are validated or by an Abort if the modifications are abandoned —
the data are then restored to the state it was in prior to the transaction.
This mechanism is extremely useful for:
* Securing editing operations (if an error occurs, the transaction is abandoned and the structure retains its integrity)
* Simplifying the implementation of the Cancel function (when the end-user begins a command,
the application may launch a transaction and operate directly in the data structure;
abandoning the action causes the transaction to Abort)
* Executing Undo (at commit time, the modifications are recorded in order to be able to restore the data to their previous state)
The transaction mechanism consists simply of managing a backup copy of attributes.
During a transaction, attributes are copied before their first modification.
If the transaction is validated, the copy is destroyed.
If the transaction is abandoned, the attribute is restored to its initial value
(when attributes are added or deleted, the operation is simply reversed).
Transactions are document-centered, that is, the application starts a transaction on a document.
So, modifying a referenced document and updating one of its referencing documents requires
two transactions, even if both operations are done in the same working session.
@subsection ocaf_wp_2_3 Persistent Data Storage
@subsubsection ocaf_wp_2_3_1 Introduction
In OCAF, persistence, that is, the mechanism used to save a document in a file, is based on an explicit formal description of the data saved.
When you open a document, the application reads the corresponding file and first creates a memory representation of it. This representation is then converted to the application data model — the OCAF-based data structure the application operates on. The file's memory representation consists of objects defined by classes known as persistent.
The persistent classes needed by an application to save its documents make the application's data schema. This schema defines the way the data are organized in the file — the format of the data. In other words, the file is simply an ASCII dump of the persistent data defined by the schema, the persistent data being created from the application data model during the save process.
Only canonical information is saved. As a matter of fact, the application data model usually contains additional data to optimize processing. For example, the persistent Bézier curve is defined by its poles, whereas its data model equivalent also contains coefficients used to compute a point at a given parameter. The additional data is calculated when the document is opened.
The major advantages of this approach are the following:
* Providing that the data format is published, files created by OCAF-based applications
can be read without needing a runtime of the application (openness)
* Although the persistence approach makes the data format more stable,
OCAF provides a framework for managing compatibility of data between versions of the application —
modification of the data format is supported through the versioning of schema.
OCAF includes a ready-to-use schema suitable for most applications.
However, it can be extended if needed. For that, the only things you have to do are:
* To define the additional persistent attributes
* To implement the functions converting these persistent attribute to and from the application data model.
Applications using compound documents extensively (saving data in many files linked together) should implement data management services. As a matter of fact, it's out the scope of OCAF to provide functions such as:
* Version and configuration management of compound documents;
* Querying a referenced document for its referencing documents.
In order to ease the delegation of document management to a data management application, OCAF encapsulates the file management functions in a driver (the meta-data driver). You have to implement this driver for your application to communicate with the data management system of your choice.
@subsubsection ocaf_wp_2_3_2 Schemes of Persistence
There are three schemes of persistence, which you can use to store and retrieve OCAF data (documents):
* <i> Standard</i> persistence schema, compatible with previous OCAF applications
* <i> XmlOcaf</i> persistence, allowing the storage of all OCAF data in XML form
* <i> BinOcaf</i> persistence, allowing the storage of all OCAF data in binary format form
All schemes are independent of each other, but they guarantee that the standard OCAF
attributes stored and retrieved by one schema will be storable and retrievable by
the other. Therefore in any OCAF application you can use any persistence schema or
even all three of them. The choice is made depending on the *Format* string of stored OCAF documents
or automatically by the file header data - on retrieval.
Persistent data storage in OCAF using the <i> Standard</i> package is presented in:
* Basic Data Storage
* Persistent Collections
Persistent storage of shapes is presented in the following chapters:
* Persistent Geometry
* Persistent Topology
Finally, information about opening and saving persistent data is presented in Standard
Documents.
@subsubsection ocaf_wp_2_3_3 Basic Data Storage
Normally, all data structures provided by Open CASCADE Technology are run-time structures,
in other words, transient data. As transient data, they exist only while an application
is running and are not stored permanently. However, the Data Storage module provides
resources, which enable an application to store data on disk as persistent data.
Data storage services also provide libraries of persistent classes and translation
functions needed to translate data from transient to persistent state and vice-versa.
#### Libraries of persistent classes
Libraries of persistent classes are extensible libraries of elementary classes you
use to define the database schema of your application. They include:
* Unicode (8-bit or 16-bit character type) strings
* Collections of any kind of persistent data such as arrays.
All persistent classes are derived from the \b Persistent base class, which defines
a unique way of creating and handling persistent objects. You create new persistent
classes by inheriting from this base class.
#### Translation Functions
Translation functions allow you to convert persistent objects to transient ones and
vice-versa. These translation functions are used to build Storage and Retrieval drivers
of an application.
For each class of 2D and 3D geometric types, and for the general shape class in the
topological data structure library, there are corresponding persistent class libraries,
which allow you to translate your data with ease.
#### Creation of Persistent Classes
If you use Unix platforms as well as WOK and CDL, you can create your own persistent
classes. In this case, data storage is achieved by implementing *Storage* and *Retrieval*
drivers.
The <i> Storage </i> package is used to write and read persistent objects.
These objects are read and written by a retrieval or storage algorithm
(<i> Storage_Schema </i>object) in a container (disk, memory, network ...).
Drivers (<i> FSD_File</i> objects) assign a physical container for data to be stored or retrieved.
The standard procedure for an application in reading a container is as follows:
* open the driver in reading mode,
* call the Read function from the schema, setting the driver as a parameter. This function returns an instance of the <i> Storage_Data </i> class which contains the data being read,
* close the driver.
The standard procedure for an application in writing a container is as follows:
* open the driver in writing mode,
* create an instance of the <i> Storage_Data </i> class, then add the persistent data to write with the function <i> AddRoot</i>,
* call the function <i> Write </i> from the schema, setting the driver and the <i> Storage_Data </i> instance as parameters,
* close the driver.
@subsubsection ocaf_wp_2_3_4 Persistent Collections
Persistent collections are classes which handle dynamically sized collections of data that can be stored in the database. These collections provide three categories of service:
* persistent strings,
* generic arrays of data,
* commonly used instantiations of arrays.
Persistent strings are concrete classes that handle sequences of characters based
on both ASCII (normal 8-bit) and Unicode (16-bit) character sets.
Arrays are generic classes, that is, they can hold a variety of objects not necessarily inheriting from a unique root class. These arrays can be instantiated with any kind of storable or persistent object, and then inserted into the persistent data model of a user application.
The purpose of these data collections is simply to convert transient data into its persistent equivalent so that it can be stored in the database. To this end, the collections are used to create the persistent data model and assure the link with the database. They do not provide editing or query capabilities because it is more efficient, within the operative data model of the application, to work with transient data structures (from the <i> TCollection</i> package).
For this reason:
* the persistent strings only provide constructors and functions to convert between transient and persistent strings, and
* the persistent data collections are limited to arrays. In other words, <i> PCollection</i> does not include sequences, lists, and so on (unlike <i> TCollection</i>).
Persistent string and array classes are found in the <i> PCollection</i> package. In addition, <i> PColStd</i> package provides standard, and frequently used, instantiations of persistent arrays, for very simple objects.
@subsubsection ocaf_wp_2_3_5 Persistent Geometry
The Persistent Geometry component describes geometric data structures which can be stored in the database. These packages provide a way to convert data from the transient "world" to the persistent "world".
Persistent Geometry consists of a set of atomic data models parallel to the geometric data structures described in the geometry packages. Geometric data models, independent of each other, can appear within the data model of any application. The system provides the means to convert each atomic transient data model into a persistent one, but it does not provide a way for these data models to share data.
Consequently, you can create a data model using these components, store data in, and retrieve it from a file or a database, using the geometric components provided in the transient and persistent "worlds". In other words, you customize the system by declaring your own objects, and the conversion of the geometric components from persistent to transient and vice versa is automatically managed for you by the system.
However, these simple objects cannot be shared within a more complex data model. To allow data to be shared, you must provide additional tools.
Persistent Geometry is provided by several packages.
The <i> PGeom</i> package describes geometric persistent objects in 3D space, such as points,
vectors, positioning systems, curves and surfaces.
These objects are persistent versions of those provided by the <i> Geom</i> package: for
each type of transient object provided by Geom there is a corresponding type of persistent
object in the <i>PGeom</i> package. In particular the inheritance structure is parallel.
However the <i> PGeom </i>package does not provide any functions to construct, edit or access
the persistent objects. Instead the objects are manipulated as follows:
* Persistent objects are constructed by converting the equivalent transient <i> Geom </i> objects. To do this you use the <i>MgtGeom::Translate</i> function.
* Persistent objects created in this way are used to build persistent data structures that are then stored in a file or database.
* When these objects are retrieved from the file or database, they are converted back into the corresponding transient objects from the Geom package. To do this, you use <i>MgtGeom::Translate</i> function.
In other words, you always edit or query transient data structures within the transient
data model supplied by the session.
Consequently, the documentation for the <i> PGeom </i> package consists simply of a list of available objects.
The <i> PGeom2d </i> package describes persistent geometric objects in 2D space, such as points,
vectors, positioning systems and curves. This package provides the same type of services
as the <i> PGeom</i> package, but for the 2D geometric objects provided by the <i> Geom2d</i> package.
Conversions are provided by the <i>MgtGeom::Translate</i> function.
~~~~
//Create a coordinate system
Handle(Geom_Axis2Placement) aSys;
//Create a persistent coordinate PTopoDS_HShape.cdlsystem
Handle(PGeom_Axis2placement)
aPSys = MgtGeom::Translate(aSys);
//Restore a transient coordinate system
Handle(PGeom_Axis2Placement) aPSys;
Handle(Geom_Axis2Placement)
aSys = MgtGeom::Translate(aPSys);
~~~~
@subsubsection ocaf_wp_2_3_6 Persistent Topology
The Persistent Topology component describes topological data structures which can be stored in the database. These packages provide a way to convert data from the transient "world" to the persistent "world".
Persistent Topology is based on the BRep concrete data model provided by the topology packages. Unlike the components of the Persistent Geometry package, topological components can be fully shared within a single model, as well as between several models.
Each topological component is considered to be a shape: a <i> TopoDS_Shape</i> object. The system's capacity to convert a transient shape into a persistent shape and vice-versa applies to all objects, irrespective of their complexity: vertex, edge, wire, face, shell, solid, and so on.
When a user creates a data model using BRep shapes, he uses the conversion functions that the system provides to store the data in, and retrieve it from the database. The data can also be shared.
Persistent Topology is provided by several packages.
The <i> PTopoDS</i> package describes the persistent data model associated with any BRep shape; it is the persistent version of any shape of type <i> TopoDS_Shape</i>. As is the case for persistent geometric models, this data structure is never edited or queried, it is simply stored in or retrieved from the database. It is created or converted by the <i>MgtBRep::Translate</i> function.
The <i> MgtBRepAbs</i> and <i> PTColStd </i> packages provide tools used by the conversion functions of topological objects.
~~~~
//Create a shape
TopoDS_Shape aShape;
//Create a persistent shape
PtColStd_DoubleTransientPersistentMap aMap;
Handle(PTopoDS_HShape) aPShape =
aMap.Bind2(MgtBRep::Translate
aShape,aMap,MgtBRepAbs_WithTriangle));
aPShape.Nullify();
//Restore a transient shape
Handle(PTopoDS_HShape) aPShape;
Handle(TopoDS_HShape) aShape =
aMap.Bind1(MgtBRep::Translate
(aPShape,aMap,MgtBRepAbs_WithTriangle));
aShape.Nullify();
~~~~
@subsubsection ocaf_wp_2_3_7 Standard Documents
Standard documents offer you a ready-to-use document containing a TDF-based data
structure. The documents themselves are contained in a class inheriting from <i> TDocStd_Application</i>
which manages creation, storage and retrieval of documents.
You can implement undo and redo in your document, and refer from the data framework
of one document to that of another one. This is done by means of external link attributes,
which store the path and the entry of external links. To sum up, standard documents
alone provide access to the data framework. They also allow you to:
* Update external links;
* Manage the saving and opening of data;
* Manage undo/redo functionality.

View File

@@ -445,7 +445,7 @@ Let us correct the following wire:
@image html /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape"
@image latex /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape"
It is necessary to apply the <a href="#_3_1_2">Tools for the analysis of validity of wires</a> to check that:
It is necessary to apply the @ref occt_shg_3_1_2 "tools for the analysis of wire validity" to check that:
* the edges are correctly oriented;
* there are no edges that are too short;
* there are no intersecting adjacent edges;
@@ -504,7 +504,7 @@ To see how this tool works, it is possible to take an edge, where the maximum de
@image html /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape"
@image latex /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape"
First it is necessary to apply the <a href="#_3_1_3">Tool for checking the validity of edges</a> to find that maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable.
First it is necessary to apply the @ref occt_shg_3_1_3 "tool for checking the edge validity" to find that the maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable.
~~~~~
ShapeAnalysis_Edge sae;

View File

@@ -16,7 +16,7 @@ Open Cascade allows its users to employ STEP in the following domains:
This manual is intended to provide technical documentation on the Open CASCADE Technology (**OCCT**) STEP processor and to help Open CASCADE Technology users with the use of the STEP processor (to read and write STEP files).
Only geometrical, topological STEP entities (shapes) and assembly structures are translated by the basic translator described in sections 2 to 6. Data that cannot be translated on this level are also loaded from a STEP file and can be translated later. XDE STEP translator (see section 7 <a href="#occt_step_7">Reading from and writing to XDE</a>) translates names, colors, layers, validation properties and other data associated with shapes and assemblies into XDE document.
Only geometrical, topological STEP entities (shapes) and assembly structures are translated by the basic translator described in sections 2 to 6. Data that cannot be translated on this level are also loaded from a STEP file and can be translated later. XDE STEP translator (see section 7 @ref occt_step_7 "Reading from and writing to XDE") translates names, colors, layers, validation properties and other data associated with shapes and assemblies into XDE document.
File translation is performed in the programming mode, via C++ calls.
@@ -105,7 +105,7 @@ The types of STEP topological entities that can be translated are:
* faces
* shells
* solids
For further information see <a href="#occt_step_2_4">Mapping STEP entities to Open CASCADE Technology shapes</a>.
For further information see @ref occt_step_2_4 "Mapping STEP entities to Open CASCADE Technology shapes".
@subsubsection occt_step_2_2_4 Geometrical entities
The types of STEP geometrical entities that can be translated are:
@@ -283,10 +283,6 @@ Default values:
* read.step.resource.name - STEP,
* read.step.sequence - FromSTEP.
<h4>read.scale.unit</h4>
This parameter is obsolete (the parameter *xstep.cascade.unit* should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
Default value is MM.
<h4>xstep.cascade.unit</h4>
This parameter defines units to which a shape should be converted when translated from IGES or STEP to CASCADE. Normally it is MM; only those applications that work internally in units other than MM should use this parameter.
@@ -797,7 +793,7 @@ The shapes organized in a structure of nested compounds can be translated either
The assembly structure placed in the produced STEP file corresponds to the structure described in the ProSTEP Agreement Log (item 21) as the second alternative (assembly structure through *representation_relationship* / *item_defined_transformation*). To represent an assembly it uses entities of the *representation_relationship_with_transformation* type. Transformation operators used for locating assembly components are represented by *item_defined_transformation* entities.
If mode *write.step.assembly* is set to the values *ON* or *Auto* then an OCC shape consisting of nested compounds will be written as an assembly, otherwise it will be written as separate solids.
Please see also <a href="#occt_step_3_4">Mapping OCCT shapes to STEP entities</a>
Please see also @ref occt_step_3_4 "Mapping OCCT shapes to STEP entities".
@subsection occt_step_3_3 Description of the process
@subsubsection occt_step_3_3_1 Initializing the process
@@ -1180,7 +1176,7 @@ Physical file writing consists of the following steps:
If it is necessary to write and translate an OCCT shape into a new entity by the STEP processor the Writer and Actor scope should be enhanced.
For a description of steps, which should be taken for adding a new entity type to the STEP processor, see <a href="#occt_step_4_2">Physical file reading</a>. Then, enhance the *STEPControl_ActorWrite* class i.e. methods *Recognize()* and *Transfer()*, or other classes from *TopoDSToStep*, to translate the OCCT shape into a new STEP entity.
For a description of steps, which should be taken for adding a new entity type to the STEP processor, see @ref occt_step_4_2 "Physical file reading". Then, enhance the *STEPControl_ActorWrite* class i.e. methods *Recognize()* and *Transfer()*, or other classes from *TopoDSToStep*, to translate the OCCT shape into a new STEP entity.
@section occt_step_6 Using DRAW
@subsection occt_step_6_1 DRAW STEP Commands Overview
@@ -1209,9 +1205,9 @@ Command xtrace is intended to view and change these parameters:
@subsection occt_step_6_3 Reading a STEP file
For a description of parameters used in reading a STEP file refer to <a href="#occt_step_2_3_3">Setting the translation parameters</a> section.
For a description of parameters used in reading a STEP file refer to @ref occt_step_2_3_3 "Setting the translation parameters" section.
For reading a STEP file, the following parameters are defined (see above, <a href="#occt_step_6_2">the command *param*</a>):
For reading a STEP file, the following parameters are defined (see above, @ref occt_step_6_2 "the command *param*"):
| Description | Name | Values | Meaning |
| :------------ | :---- | :------- | :------- |
@@ -1361,7 +1357,7 @@ When specifying min and max arguments this command saves shapes with tolerances
* *c* - for shells and faces.
@subsection occt_step_6_5 Writing a STEP file
For writing shapes to a STEP file, the following parameters are defined (see above, <a href="#occt_step_6_2">the command *param*</a>):
For writing shapes to a STEP file, the following parameters are defined (see above, @ref occt_step_6_2 "the command *param*"):
| Description | Name | Values | Meaning |
| :------------ | :----- | :------ | :------- |
@@ -1410,10 +1406,10 @@ IFSelect_ReturnStatus stat = reader.ReadFile("filename.stp");
Loading the file only memorizes the data, it does not translate it.
@subsubsection occt_step_7_1_2 Checking the loaded STEP file
This step is not obligatory. See a description of this step in section <a href="#occt_step_2_3_2">Checking the STEP file</a>.
This step is not obligatory. See a description of this step in section @ref occt_step_2_3_2 "Checking the STEP file".
@subsubsection occt_step_7_1_3 Setting the parameters for translation to XDE
See a description of this step in section <a href="#occt_step_2_3_3">Setting the translation parameters</a>.
See a description of this step in section @ref occt_step_2_3_3 "Setting the translation parameters".
In addition, the following parameters can be set for XDE translation of attributes:
* Parameter for transferring colors:

View File

@@ -16,8 +16,5 @@ OCCT User Guides are organized by OCCT modules:
* @subpage occt_user_guides__step "STEP translator"
* @subpage occt_user_guides__xde "Extended Data Exchange (XDE)"
* @subpage occt_user_guides__ocaf "Open CASCADE Application Framework (OCAF)"
* @subpage occt_user_guides__ocaf_wp "Application Framework White Paper"
* @subpage occt_user_guides__ocaf_functionmechanism_wp "OCAF Function Mechanism"
* @subpage occt_user_guides__ocaf_tree_wp "Distribution of Data through OCAF Tree"
* @subpage occt_user_guides__tobj "TObj package"
* @subpage occt_user_guides__test_harness "DRAW Test Harness"

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

View File

@@ -0,0 +1,152 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="492.51703"
height="62.516983"
id="svg4916"
version="1.1"
inkscape:version="0.48.4 r9939"
sodipodi:docname="vis_image007.svg">
<defs
id="defs4918" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1"
inkscape:cx="199.2585"
inkscape:cy="34.120675"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="1202"
inkscape:window-height="813"
inkscape:window-x="43"
inkscape:window-y="80"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0" />
<metadata
id="metadata4921">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-105.7415,-304.10369)">
<text
xml:space="preserve"
x="373.58167"
y="326.15771"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
id="text3030">IShapeData </text>
<text
transform="scale(0.7861951,1.2719489)"
id="text6803"
xml:space="preserve"
x="146.32727"
y="269.49332"
style="font-size:27.75222969px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">IShape </text>
<rect
style="fill:none;stroke:#000000;stroke-width:1.23895466;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect5880"
width="95.278046"
height="59.278049"
x="106.36098"
y="305.72314"
ry="17.124769" />
<path
id="path4102"
d="m 223.52817,321.64549 0,6.35835 -16.58451,0 0,12.71669 16.58451,0 0,6.35835 5.52817,-12.7167 z"
style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:0.65600133px;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
inkscape:connector-curvature="0" />
<rect
style="fill:none;stroke:#000000;stroke-width:1.23895466;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect5880-4"
width="95.278046"
height="59.278049"
x="232.36096"
y="306.72314"
ry="17.124769" />
<text
transform="scale(0.88816375,1.1259185)"
id="text6805-8"
xml:space="preserve"
x="276.47144"
y="290.76089"
style="font-size:20.63711739px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">IShape</text>
<text
transform="scale(0.8743505,1.1437061)"
id="text6805-82"
xml:space="preserve"
x="283.47748"
y="307.15155"
style="font-size:20.20298386px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">Mesher</text>
<path
id="path4102-4"
d="m 348.52817,321.64549 0,6.35835 -16.58451,0 0,12.71669 16.58451,0 0,6.35835 5.52817,-12.7167 z"
style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:0.65600133px;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
inkscape:connector-curvature="0" />
<rect
style="fill:none;stroke:#000000;stroke-width:1.39507556;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect5880-4-5"
width="121.12193"
height="59.121929"
x="357.43903"
y="306.80121"
ry="17.079668" />
<text
xml:space="preserve"
x="361.1011"
y="342.28717"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
id="text3030-5">Implementation</text>
<text
xml:space="preserve"
x="382.74277"
y="357.28717"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
id="text3030-5-1">for VTK</text>
<path
id="path4102-4-7"
d="m 500.52817,321.64549 0,6.35835 -16.58451,0 0,12.71669 16.58451,0 0,6.35835 5.52817,-12.7167 z"
style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:0.65600133px;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
inkscape:connector-curvature="0" />
<rect
style="fill:#00ffff;stroke:#000000;stroke-width:1.19996607;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect5880-4-5-1"
width="89.317047"
height="59.317039"
x="508.34149"
y="304.70367"
ry="17.136032" />
<text
transform="scale(0.83864381,1.1924013)"
id="text6805-8-1"
xml:space="preserve"
x="607.78577"
y="285.37732"
style="font-size:15.50377846px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">vtkPolyData</text>
</g>
</svg>

After

Width:  |  Height:  |  Size: 6.0 KiB

View File

@@ -281,7 +281,7 @@ The usage of low-level tools is justified in cases when the utilities from *IVtk
The low-level scenario of VIS usage in VTK pipeline is shown in the figure below. The Mesher component produces shape facet (VTK polygonal data) using implementation of *IShapeData* interface. Then result can be retrieved from this implementation as a *vtkPolyData* instance.
@figure{/user_guides/vis/images/vis_image007.png "Low-level VIS usage with VTK"}
@figure{/user_guides/vis/images/vis_image007.svg "Low-level VIS usage with VTK"}
The visualization pipeline for OCCT shape presentation can be initialized as follows:
1. Create an instance of *IShape* class initialized by OCCT topological shape:

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

View File

@@ -0,0 +1,388 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="642.85785"
height="522.1217"
id="svg4656"
version="1.1"
inkscape:version="0.48.4 r9939"
sodipodi:docname="visualization_image004.svg">
<defs
id="defs4658">
<marker
inkscape:stockid="Arrow2Lstart"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lstart"
style="overflow:visible">
<path
inkscape:connector-curvature="0"
id="path7116"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(1.1,0,0,1.1,1.1,0)" />
</marker>
<marker
inkscape:stockid="Arrow2Lstart"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lstart-2"
style="overflow:visible">
<path
inkscape:connector-curvature="0"
id="path7116-1"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(1.1,0,0,1.1,1.1,0)" />
</marker>
<marker
inkscape:stockid="Arrow2Lstart"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lstart-7"
style="overflow:visible">
<path
inkscape:connector-curvature="0"
id="path7116-9"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(1.1,0,0,1.1,1.1,0)" />
</marker>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1"
inkscape:cx="310.01454"
inkscape:cy="256.97846"
inkscape:document-units="px"
inkscape:current-layer="g9010"
showgrid="false"
inkscape:window-width="964"
inkscape:window-height="869"
inkscape:window-x="110"
inkscape:window-y="110"
inkscape:window-maximized="0"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0" />
<metadata
id="metadata4661">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-87.454854,-473.93551)">
<g
id="g9010">
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:1.14259863px;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
clip-path="url(#clipEmfPath0)"
d="m 144.5394,804.00145 c -30.36322,0 -54.967887,15.2339 -54.967887,34.03321 0,18.7993 24.604667,34.03319 54.967887,34.03319 30.3632,0 54.96788,-15.23389 54.96788,-34.03319 0,-18.79931 -24.60468,-34.03321 -54.96788,-34.03321"
id="path3298-1" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:1.21930075px;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
clip-path="url(#clipEmfPath0)"
d="m 144,919.27681 c -30.89771,0 -55.935496,17.04774 -55.935496,38.08539 0,21.03765 25.037786,38.08539 55.935496,38.08539 30.89769,0 55.93549,-17.04774 55.93549,-38.08539 0,-21.03765 -25.0378,-38.08539 -55.93549,-38.08539"
id="path3298-1-7" />
<g
transform="translate(-3,-4)"
id="g7007">
<path
id="path3028"
d="m 221.70549,791.45369 0,102.81698 236.58902,0 0,-102.81698 z"
style="fill:none;stroke:#000000;stroke-width:2.03636551px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
inkscape:connector-curvature="0" />
<text
id="text3030"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="855.65771"
x="240.58167"
xml:space="preserve">uses algorithms of Prs3D </text>
<text
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="868.65771"
x="246.58167"
xml:space="preserve"
id="text6807">and StdPrs packages to </text>
<text
style="font-size:15.67667294px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="752.18933"
x="296.65607"
xml:space="preserve"
id="text6803"
transform="scale(0.92214786,1.0844248)">Class AIS_Shape </text>
<text
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="757.59094"
x="330.80762"
xml:space="preserve"
id="text6805"
transform="scale(0.90547757,1.1043896)">Compute()</text>
<text
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="882.28711"
x="229.76691"
xml:space="preserve"
id="text6807-9">create Graphics3d structure </text>
</g>
<path
inkscape:connector-curvature="0"
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.11899135px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
d="m 199.62164,835.29171 14.20318,-0.59253 c 0.2177,0 0.39421,0.27272 0.40004,0.61131 0.007,0.34803 -0.16469,0.63953 -0.3824,0.64897 l -14.19727,0.5831 c -0.21769,0.01 -0.39419,-0.2634 -0.4001,-0.60198 -0.007,-0.34793 0.16477,-0.63943 0.37655,-0.64887 z m 13.36769,-3.68664 4.76573,3.56434 -4.64222,3.95002 z"
id="path3010" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:1.40559888px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
d="m 217.3901,936.6383 0,48.44779 239.2198,0 0,-48.44779 z"
id="path3028-4" />
<path
inkscape:connector-curvature="0"
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.12212796px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
d="m 199.64351,958.2917 14.96808,-0.59231 c 0.22942,0 0.41543,0.27262 0.42158,0.61102 0.007,0.34795 -0.17356,0.63928 -0.40299,0.64873 l -14.96187,0.58287 c -0.22941,0.01 -0.41542,-0.26328 -0.42164,-0.60177 -0.007,-0.34775 0.17364,-0.63908 0.39684,-0.64854 z m 14.0876,-3.68514 5.02238,3.56286 -4.89222,3.94842 z"
id="path3010-8" />
<text
transform="scale(0.90547756,1.1043896)"
id="text6805-8"
xml:space="preserve"
x="282.51627"
y="872.30591"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">Topological Object</text>
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:2.12761998px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
d="m 470.75112,864.99932 0,102.72572 258.49776,0 0,-102.72572 z"
id="path3028-2" />
<text
transform="scale(0.92214786,1.0844248)"
id="text6803-4"
xml:space="preserve"
x="530.02728"
y="824.57794"
style="font-size:15.67667294px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">StdPrs and Prs3d packages </text>
<text
xml:space="preserve"
x="493.69882"
y="920.38812"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
id="text3030-5">Contain various algorithms </text>
<text
id="text6807-1"
xml:space="preserve"
x="476.76691"
y="936.28711"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">to transform object structures </text>
<text
id="text6807-9-7"
xml:space="preserve"
x="492.01605"
y="951.38818"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">into Graphics3d structures </text>
<path
inkscape:connector-curvature="0"
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09031779px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
d="m 336.80311,932.90806 0.0571,-40.42973 c 0,-0.12142 0.28555,-0.22261 0.63772,-0.22261 0.35218,0 0.63773,0.10119 0.63773,0.22598 l -0.0572,40.42636 c 0,0.12477 -0.28555,0.22599 -0.63772,0.22599 -0.35218,0 -0.63773,-0.10122 -0.63773,-0.22599 z m 4.44506,-0.44857 -3.80733,2.69823 -3.80734,-2.69823 z m -7.55756,-39.52921 3.80734,-2.69824 3.80734,2.69824 z"
id="path7377" />
<path
inkscape:connector-curvature="0"
id="path21911"
d="m 219,707.54039 0,75.64359"
style="fill:none;stroke:#000000;stroke-width:0.7003088;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:2.10092636, 2.10092636;stroke-dashoffset:0" />
<path
inkscape:connector-curvature="0"
id="path21911-1"
d="m 453.5,707.46465 0,77.79507"
style="fill:none;stroke:#000000;stroke-width:0.58958817;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:1.76876451, 1.76876451;stroke-dashoffset:0" />
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:2.24281454px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
d="m 165.30872,475.05692 0,72.61052 406.38256,0 0,-72.61052 z"
id="path3028-2-1" />
<g
transform="translate(-5,-185.5)"
id="g7007-5">
<path
id="path3028-27"
d="m 221.70549,791.45369 0,102.81698 236.58902,0 0,-102.81698 z"
style="fill:none;stroke:#000000;stroke-width:2.03636551px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
inkscape:connector-curvature="0" />
<text
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="868.65771"
x="231.58167"
xml:space="preserve"
id="text6807-14">Declares Compute() method </text>
<text
style="font-size:15.67667294px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="752.18933"
x="296.65607"
xml:space="preserve"
id="text6803-2"
transform="scale(0.92214786,1.0844248)">Deferred class </text>
<text
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
y="756.68549"
x="270.06619"
xml:space="preserve"
id="text6805-3"
transform="scale(0.90547756,1.1043896)">AIS_InteractiveObject</text>
<path
inkscape:connector-curvature="0"
id="path13459"
d="m 368.70052,894.03606 -47.83744,77.21358"
style="fill:none;stroke:#000000;stroke-width:1.27159095px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:none" />
</g>
<path
inkscape:connector-curvature="0"
id="path13459-6"
d="M 535.32214,863.39163 454.93725,806.09542"
style="fill:none;stroke:#000000;stroke-width:1.41992795px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:none" />
<text
transform="scale(0.90547756,1.1043896)"
id="text6805-8-8"
xml:space="preserve"
x="543.32458"
y="749.08734"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">uses</text>
<text
transform="scale(0.90547756,1.1043896)"
id="text6805-8-8-5"
xml:space="preserve"
x="385.70276"
y="682.21692"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">inherits</text>
<path
inkscape:connector-curvature="0"
style="fill:none;stroke:#000000;stroke-width:1.2751534px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
d="m 479.32488,631.07307 0,48.57823 196.35024,0 0,-48.57823 z"
id="path3028-4-7" />
<text
transform="scale(0.90547756,1.1043896)"
id="text6805-8-6"
xml:space="preserve"
x="544.42902"
y="597.87256"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">Object presentation</text>
<path
inkscape:connector-curvature="0"
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.14474645px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
d="m 452.8172,658.29188 21.08928,-0.5905 c 0.32324,0 0.58532,0.27179 0.59399,0.60922 0.01,0.34683 -0.24455,0.63734 -0.5678,0.64674 l -21.08051,0.5811 c -0.32323,0.01 -0.58531,-0.26249 -0.59408,-0.59991 -0.01,-0.34674 0.24465,-0.63724 0.55912,-0.64665 z m 19.84871,-3.674 7.07629,3.55212 -6.8929,3.93648 z"
id="path3010-1" />
<text
transform="scale(0.90547756,1.1043896)"
id="text6805-8-6-8"
xml:space="preserve"
x="269.14154"
y="446.65784"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">Class PresentationManager3d</text>
<text
xml:space="preserve"
x="175.31769"
y="514.28717"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
id="text3030-5-9">calls Compute() method of AIS_InteractiveObject</text>
<text
xml:space="preserve"
x="174.40979"
y="530.71832"
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
id="text3030-5-9-2">to obtain Graphics3d structure</text>
<path
inkscape:connector-curvature="0"
id="path13459-6-5"
d="M 561.27709,629.42121 457.63979,547.78428"
style="fill:none;stroke:#000000;stroke-width:1.92449844px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:none" />
<text
transform="scale(0.90547756,1.1043896)"
id="text6805-8-8-4"
xml:space="preserve"
x="571.24023"
y="521.04193"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">deals with</text>
<text
transform="scale(0.90547756,1.1043896)"
id="text6805-8-8-4-3"
xml:space="preserve"
x="398.07434"
y="519.80078"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">calls</text>
<text
inkscape:transform-center-y="94"
inkscape:transform-center-x="-61"
transform="scale(0.90547756,1.1043896)"
id="text6805-8-8-4-1"
xml:space="preserve"
x="398.07431"
y="535.19385"
style="font-size:16.73931694px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">Compute()</text>
<path
inkscape:connector-curvature="0"
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.210106px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
d="m 339.06968,549.84169 0.58535,44.82599 c 0,0.68706 -0.26941,1.24411 -0.6039,1.26254 -0.3438,0.0212 -0.63178,-0.5198 -0.64109,-1.20688 l -0.57603,-44.80735 c -0.01,-0.68703 0.26019,-1.24409 0.59467,-1.26273 0.34371,-0.0213 0.63168,0.52001 0.641,1.18843 z m 3.64194,42.18911 -3.52112,15.0409 -3.90212,-14.6511 z"
id="path3010-2" />
<text
transform="scale(0.88347213,1.1318976)"
id="text6805-8-8-5-1"
xml:space="preserve"
x="112.37634"
y="733.97705"
style="font-size:14.97209454px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">Creation of</text>
<text
transform="scale(0.88347214,1.1318976)"
id="text6805-8-8-5-1-7"
xml:space="preserve"
x="119.76624"
y="746.78375"
style="font-size:14.97209454px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">AIS_Shape</text>
<text
transform="scale(0.88347214,1.1318976)"
id="text6805-8-8-5-1-4"
xml:space="preserve"
x="112.97488"
y="839.54834"
style="font-size:14.97209454px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">Creation of</text>
<text
transform="scale(0.88347214,1.1318976)"
id="text6805-8-8-5-1-0"
xml:space="preserve"
x="112.99133"
y="853.70294"
style="font-size:14.97209454px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">topological</text>
<text
transform="scale(0.88347214,1.1318976)"
id="text6805-8-8-5-1-9"
xml:space="preserve"
x="132.23358"
y="867.8385"
style="font-size:14.97209454px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New">object</text>
</g>
</g>
</svg>

After

Width:  |  Height:  |  Size: 20 KiB

View File

@@ -33,8 +33,8 @@ The figure below presents a schematic overview of the relations between the key
To answer different needs of CASCADE users, this User's Guide offers the following three paths in reading it.
* If the 3D services proposed in AIS meet your requirements, you need only read chapter 3 <a href="#occt_visu_3">AIS: Application Interactive Services</a>.
* If you need more detail, for example, a selection filter on another type of entity - you should read chapter 2 <a href="#occt_visu_2">Fundamental Concepts</a>, chapter 3 <a href="#occt_visu_3">AIS: Application Interactive Services</a>, and 4 <a href="#occt_visu_4">3D Presentations</a>. You may want to begin with the chapter presenting AIS.
* If the 3D services proposed in AIS meet your requirements, you need only read chapter 3 @ref occt_visu_3 "AIS: Application Interactive Services".
* If you need more detail, for example, a selection filter on another type of entity - you should read chapter 2 @ref occt_visu_2 "Fundamental Concepts", chapter 3 @ref occt_visu_3 "AIS: Application Interactive Services", and 4 @ref occt_visu_4 "3D Presentations". You may want to begin with the chapter presenting AIS.
For advanced information on visualization algorithms, see our <a href="http://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
@@ -164,7 +164,7 @@ The interactive context is used to manage both selectable objects and selection
Selection modes may be activated or de-activated for given selectable objects. Information is then provided about the status of activated/de-activated selection modes for a given object in a given selector.
See also <a href="#occt_visu_3">AIS: Application Interactive Services</a>.
See also @ref occt_visu_3 "AIS: Application Interactive Services".
Let us consider, for example, a 3D selectable shape object, which corresponds to a topological shape.
@@ -502,7 +502,7 @@ Inside these categories, additional characterization is available by means of a
* *AIS_InteractiveObject::Type*
* *AIS_InteractiveObject::Signature*.
**Note** that some signatures are already used by "standard" objects provided in AIS (see the <a href="#occt_visu_3_5">list of Standard Interactive Object Classes</a>).
**Note** that some signatures are already used by "standard" objects provided in AIS (see the @ref occt_visu_3_5 "List of Standard Interactive Object Classes".
The interactive context can have a default mode of representation for the set of interactive objects. This mode may not be accepted by a given class of objects.
@@ -555,7 +555,7 @@ void myPk_IsShape::Compute
@subsubsection occt_visu_3_2_4 Selection
An interactive object can have an indefinite number of selection modes, each representing a "decomposition" into sensitive primitives; each primitive has an Owner (*SelectMgr_EntityOwner*) which allows identifying the exact entity which has been detected (see <a href="#occt_visu_3_6"> Dynamic Selection</a> chapter).
An interactive object can have an indefinite number of selection modes, each representing a "decomposition" into sensitive primitives; each primitive has an Owner (*SelectMgr_EntityOwner*) which allows identifying the exact entity which has been detected (see ref occt_visu_3_6 "Dynamic Selection" chapter).
The set of sensitive primitives, which correspond to a given mode, is stocked in a SELECTION (*SelectMgr_Selection*).
@@ -563,7 +563,7 @@ Each Selection mode is identified by an index. By Convention, the default selec
The calculation of Selection primitives (or sensitive primitives) is done by the intermediary of a virtual function, *ComputeSelection*. This should be implemented for each type of interactive object on which you want to make different type selections using the function *AIS_ConnectedInteractive::ComputeSelection*.
A detailed explanation of the mechanism and the manner of implementing this function has been given in <a href="#occt_visu_3_6"> Dynamic Selection</a> chapter.
A detailed explanation of the mechanism and the manner of implementing this function has been given in @ref occt_visu_3_6 "Dynamic Selection" chapter.
Moreover, just as the most frequently manipulated entity is *TopoDS_Shape*, the most used Interactive Object is *AIS_Shape*. You will see below activation functions for standard selection modes are proposed in the Interactive context (selection by vertex, by edges etc). To create new classes of interactive object with the same behavior as *AIS_Shape* - such as vertices and edges - you must redefine the virtual function *AIS_ConnectedInteractive::AcceptShapeDecomposition*.
@@ -788,7 +788,7 @@ The specific modes of selection only concern the interactive objects, which are
The local context can be opened using method *AIS_InteractiveContext::OpenLocalContext*. The following options are available:
* *UseDisplayedObjects*: allows loading the interactive objects visualized at Neutral Point in the opened local context. If *FALSE*, the local context is empty after being opened. If *TRUE*, the objects at Neutral Point are modified by their default selection mode.
* *AllowShapeDecomposition*: *AIS_Shape* allows or prevents decomposition in standard shape location mode of objects at Neutral Point, which are type-privileged (see <a href="#occt_visu_3_2_4"> Selection</a> chapter). This Flag is only taken into account when *UseDisplayedObjects* is *TRUE*.
* *AllowShapeDecomposition*: *AIS_Shape* allows or prevents decomposition in standard shape location mode of objects at Neutral Point, which are type-privileged (see @ref occt_visu_3_2_4 "Selection" chapter). This Flag is only taken into account when *UseDisplayedObjects* is *TRUE*.
* *AcceptEraseOfObjects*: authorizes other local contexts to erase the interactive objects present in this context. This option is rarely used. The last option has no current use.
This function returns the index of the created local context. It should be kept and used when the context is closed.
@@ -1507,7 +1507,7 @@ void InteractiveBox::ComputeSelection
Selectable objects are loaded in the selection manager, which has one or more selectors; in general, we suggest assigning one selector per viewer. All you have to do afterwards is to activate or deactivate the different selection modes for selectable objects. The *SelectionManager* looks after the call to the *ComputeSelection* functions for different objects.
NOTE: This procedure is completely hidden if you use the <a href="#occt_visu_3_3"> AIS Interactive Context </a>
NOTE: This procedure is completely hidden if you use the @ref occt_visu_3_3 "AIS Interactive Context"
<h4>Example </h4>
~~~~~
@@ -2668,7 +2668,7 @@ myAISContext->Display (anAISShape);
Follow the procedure below to compute the presentable object:
1. Build a presentable object inheriting from *AIS_InteractiveObject* (refer to the Chapter on <a href="#occt_visu_2_1">Presentable Objects</a>).
1. Build a presentable object inheriting from *AIS_InteractiveObject* (refer to the Chapter on @ref occt_visu_2_1 "Presentable Objects").
2. Reuse the *Prs3d_Presentation* provided as an argument of the compute methods.
**Note** that there are two compute methods: one for a standard representation, and the other for a degenerated representation, i.e. in hidden line removal and wireframe modes.

View File

@@ -7,6 +7,8 @@ SET "OLD_PATH=%PATH%"
if exist "%~dp0env.bat" (
call "%~dp0env.bat"
) else (
type "%~dp0adm\templates\env.bat" | findstr /i /v "__CASROOT__" > "%~dp0env.bat"
)
set "TCL_EXEC=tclsh.exe"

Some files were not shown because too many files have changed in this diff Show More