Compare commits
107 Commits
CR0_extern
...
CR0-700bet
Author | SHA1 | Date | |
---|---|---|---|
|
b2c55ae578 | ||
|
fd7245ef38 | ||
|
d573adcf38 | ||
|
096ef695e1 | ||
|
3554ea68da | ||
|
7ed7467da3 | ||
|
ede9746c21 | ||
|
a2b5448a0f | ||
|
17abefd113 | ||
|
9a7b15dc60 | ||
|
86e810711f | ||
|
a1613f0a65 | ||
|
ad121848e3 | ||
|
5396886c90 | ||
|
3510db6201 | ||
|
6435b9c7fa | ||
|
54f91e0332 | ||
|
d2dfbc4d7d | ||
|
dcc0a33ebd | ||
|
d1c596cfe1 | ||
|
a3305c6e4e | ||
|
f9e256b388 | ||
|
67d7f07f51 | ||
|
27245ff9c0 | ||
|
75c15b4392 | ||
|
8f1f5a45cb | ||
|
109aa56ebe | ||
|
a687470889 | ||
|
dfadf64138 | ||
|
f85e7ddb9f | ||
|
59e4f50bf1 | ||
|
b12e1c7ba2 | ||
|
d9e9090564 | ||
|
727b5ad9fb | ||
|
59336f5c9d | ||
|
2f77210497 | ||
|
6ca259e871 | ||
|
d677b21418 | ||
|
20aeeb7be3 | ||
|
e9312c0fc2 | ||
|
4ff92abe44 | ||
|
77dbd1f155 | ||
|
4f99f761b1 | ||
|
4d6554d142 | ||
|
f4264b5adb | ||
|
9d99d3c16d | ||
|
3667907665 | ||
|
47e3009da9 | ||
|
c9e1d810ab | ||
|
905db76982 | ||
|
1ff072271f | ||
|
c785481848 | ||
|
795be040eb | ||
|
a0218ba1c5 | ||
|
325e442bce | ||
|
16420da1d4 | ||
|
a2ff7810d8 | ||
|
64b470617f | ||
|
5b70cbe8c1 | ||
|
74fb257d6c | ||
|
ad2a55b2f3 | ||
|
702ef49f22 | ||
|
3da62e0ec3 | ||
|
e1312bce25 | ||
|
6b13d5288e | ||
|
c8f62d27b0 | ||
|
ed9ce6777f | ||
|
8d27a37d80 | ||
|
2f9dedc5fe | ||
|
6e2cb64d8f | ||
|
d376db7a1e | ||
|
58cf74e0c0 | ||
|
5fb5b5c432 | ||
|
acb81c8314 | ||
|
f47afe531d | ||
|
d0fc16452d | ||
|
593f18f8ec | ||
|
f1eca450db | ||
|
a84c3447ad | ||
|
3b25c0e867 | ||
|
92efcf78a6 | ||
|
f5f4ebd07b | ||
|
6595eee796 | ||
|
4e14c88f77 | ||
|
f44aa19760 | ||
|
600f8c7f47 | ||
|
0e617b05e7 | ||
|
586db386eb | ||
|
cc6852f3e9 | ||
|
d660a72aca | ||
|
badc9305ae | ||
|
97f937cc55 | ||
|
c8b5b3d89e | ||
|
525ec87c53 | ||
|
5371131494 | ||
|
b128c89231 | ||
|
6bd94e0de9 | ||
|
f486f64d86 | ||
|
8156ddddc7 | ||
|
fbef84f9eb | ||
|
95081657f1 | ||
|
6a2ee09493 | ||
|
ce48b00930 | ||
|
c16915c713 | ||
|
4d147bf2a7 | ||
|
bd485d9691 | ||
|
31dfc19fcb |
311
CMakeLists.txt
@@ -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()
|
||||
|
||||
|
@@ -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
|
||||
|
13
adm/UDLIST
@@ -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
|
||||
|
@@ -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()
|
||||
|
@@ -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()
|
||||
|
||||
|
@@ -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 "")
|
||||
|
@@ -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()
|
@@ -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
|
||||
|
@@ -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)
|
||||
|
@@ -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()
|
||||
|
@@ -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)
|
||||
|
@@ -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()
|
||||
|
||||
|
@@ -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.")
|
||||
|
@@ -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")
|
||||
|
@@ -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)
|
||||
|
@@ -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]
|
||||
|
@@ -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
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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"
|
||||
|
@@ -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
|
||||
|
||||
|
30
adm/templates/occt_toolkit.rc.in
Normal 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
|
@@ -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
|
||||
|
67
adm/upgrade_sample_orig.dat
Normal 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();
|
||||
|
@@ -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")
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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.
|
||||
|
@@ -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
|
||||
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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 developer’s 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 developer’s 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 didn’t 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. |
|
||||
| Won’t 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.
|
||||
* User’s Reference Documentation on OCCT packages and Products supplied in the form of PDF User’s 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 User’s Reference Documentation
|
||||
|
||||
The User’s Reference Documentation is distributed among a number of User’s 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 User’s 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 user’s 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 User’s 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 Engineer’s** assistance.
|
||||
| Not a bug | It is a normal behavior in accordance with the specification of the product. |
|
||||
| No change required | The issue didn’t 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. |
|
||||
| Won’t fix | It is decided to keep the existing behavior. |
|
||||
|
Before Width: | Height: | Size: 22 KiB |
After Width: | Height: | Size: 73 KiB |
@@ -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<*>">
|
||||
<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<$T1>::Ptr*)entity)->myPtr</ExpandedItem>
|
||||
</Expand>
|
||||
</Type>
|
||||
<Type Name="opencascade::handle<*>">
|
||||
<DisplayString Condition="entity==0x00000000">NULL</DisplayString>
|
||||
<DisplayString Condition="entity!=0x00000000">{(void*)entity} [cnt={entity->count} {*entity}]</DisplayString>
|
||||
<Expand>
|
||||
<ExpandedItem>(opencascade::handle<$T1>::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<*>">
|
||||
<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] > 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) && (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->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->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>
|
||||
|
@@ -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
|
||||
|
||||
|
@@ -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.
|
||||
|
Before Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 7.6 KiB After Width: | Height: | Size: 30 KiB |
Before Width: | Height: | Size: 6.6 KiB |
Before Width: | Height: | Size: 8.8 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 7.3 KiB After Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 7.1 KiB After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 52 KiB |
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 8.6 KiB After Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 7.2 KiB After Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 167 KiB |
Before Width: | Height: | Size: 7.2 KiB After Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 9.6 KiB After Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 55 KiB After Width: | Height: | Size: 71 KiB |
Before Width: | Height: | Size: 60 KiB After Width: | Height: | Size: 70 KiB |
Before Width: | Height: | Size: 59 KiB After Width: | Height: | Size: 76 KiB |
Before Width: | Height: | Size: 95 KiB After Width: | Height: | Size: 104 KiB |
Before Width: | Height: | Size: 5.0 KiB After Width: | Height: | Size: 16 KiB |
@@ -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
|
||||
|
||||
|
@@ -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).
|
||||
|
@@ -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
|
||||
|
||||
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 106 KiB |
@@ -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
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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**
|
||||
|
||||
|
@@ -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 layer’s commands
|
||||
* XDE property’s 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:**
|
||||
~~~~
|
||||
|
@@ -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)
|
||||
|
@@ -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:
|
||||
|
Before Width: | Height: | Size: 2.6 KiB After Width: | Height: | Size: 2.6 KiB |
Before Width: | Height: | Size: 3.8 KiB After Width: | Height: | Size: 3.8 KiB |
Before Width: | Height: | Size: 9.6 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 60 KiB |
Before Width: | Height: | Size: 102 KiB After Width: | Height: | Size: 82 KiB |
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
BIN
dox/user_guides/ocaf/images/ocaf_wp_image003.png
Normal file
After Width: | Height: | Size: 18 KiB |
BIN
dox/user_guides/ocaf/images/ocaf_wp_image005.png
Normal file
After Width: | Height: | Size: 22 KiB |
BIN
dox/user_guides/ocaf/images/ocaf_wp_image006.png
Normal file
After Width: | Height: | Size: 42 KiB |
BIN
dox/user_guides/ocaf/images/ocaf_wp_image007.png
Normal file
After Width: | Height: | Size: 23 KiB |
@@ -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.
|
||||
Let’s 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.
|
||||
Let’s 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 shouldn’t 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& 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& 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& 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& res )
|
||||
{
|
||||
// The result is kept at the function label.
|
||||
Res.Append( Label() );
|
||||
}
|
||||
|
||||
// Execution of the function driver.
|
||||
Int CylinderDriver::Execute( TFunction_Logbook& 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;
|
||||
}
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
@@ -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, let’s 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.
|
||||
|
||||
Let’s 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.
|
||||
|
||||
Let’s 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 don’t 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, let’s 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.
|
||||
|
||||
Let’s 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.
|
Before Width: | Height: | Size: 19 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 35 KiB |
@@ -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.
|
||||
|
@@ -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;
|
||||
|
@@ -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:
|
||||
|
@@ -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"
|
Before Width: | Height: | Size: 22 KiB |
152
dox/user_guides/vis/images/vis_image007.svg
Normal 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 |
@@ -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:
|
||||
|
Before Width: | Height: | Size: 68 KiB |
388
dox/user_guides/visualization/images/visualization_image004.svg
Normal 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 |
@@ -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.
|
||||
|
@@ -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"
|
||||
|