1
0
mirror of https://git.dev.opencascade.org/repos/occt.git synced 2025-08-09 13:22:24 +03:00

Compare commits

..

22 Commits

Author SHA1 Message Date
abk
8415a280ed Tolerance post Build (Perform) fix was changed for BRepOffset_MakeOffset.
Standard_Boolean parameter theCopy with default value Standard_False was
added to methods LocOpe_WiresOnShape::Bind to determine whether bind
passing shape or its copy.

Tolerance post Build (Perform) fix was created for
- BiTgte_Blend,
- LocOpe_Spliter.

Commands checkshape were added to tests:
- bugs modalg_2 bug22864,
-               bug22946,
-      modalg_4 bug8842_1.

Minor change in BRepFeat_SplitShape.cxx.
2013-03-14 16:57:54 +04:00
abk
85c81d703f Tolerances were changed for input shapes in tests:
- bugs modalg_1 buc60462_2,
-               bug1255,
-               bug1255_1,
- bugs modalg_2 bug19811,
-               bug22781_1,
-               bug22781_2,
-               bug22781_3,
-               bug22781_4,
- bugs modalg_4 bug625,
-               bug767,
- bugs moddata_2 bug75_2,
- bugs vis bug288_10,
- bugs vis bug288_7,
- pipe specific A1 - A9,
-               B1 - B9,
-               C1 - C6,
-               K3 - K9,
-               L1 - L9,
-               M1 - M9,
-               N1 - N5,
-               S8 - S9,
-               T1 - T9,
-               U1 - U7.

Error messages were changed in tests and test files:
- bugs modalg_2 bug472_2,
- heal data advanced H5,
-      drop_small_edges A4.

Input shapes checks were added in test bugs modalg_4 bug8842_1.
2013-03-12 11:34:32 +04:00
abk
7aad5710fb Build fix in CDL files. 2013-03-06 15:11:32 +04:00
abk
f7e8fe1d88 Tolerance post Build (Perform) fix was changed for:
- BRepBuilderAPI_Sewing,
- BRepFeat_MakePrism,
- BRepFilletAPI_MakeChamfer,
- BRepFilletAPI_MakeFillet,
- BRepOffsetAPI_MakePipe,
- BRepOffsetAPI_MakePipeShell
so that input shapes remain unchanged by the fix.

Tolerance post Build (Perform) fix was slightly changed for:
- BRepOffsetAPI_NormalProjection,
- ShapeFix_Shape,
- ShapeUpgrade_ShapeDivide.

Correction of tolerances in input shapes was made for tests:
- blend buildevol F9,
-       complex B6,
-               B8,
-               D5,
-               E2,
-               E4,
-               E6,
-               E9,
- sewing tol_0_01 G3,
-                 G4.
2013-03-06 15:11:28 +04:00
abk
472c48335d Class BRepLib_ToleranceRule was created to work with shape tolerances by
tolerance rule.

Some code from BRepLib was moved to BRepLib_ToleranceRule.
2013-03-06 15:11:25 +04:00
abk
a8301722d0 Error message was changed in test 'bugs modalg bug10232'.
Error message was changed in test file 'heal data advanced ZD1'.
2013-03-06 15:11:21 +04:00
abk
1abff7396b Error message was changed in tests:
- blend complex F6,
-               F8,
- bugs fclasses bug309,

Error message was changed in test data files:
- chamfer data complex B5,
-                      B7,
- heal data advanced ZD3,
-           standard R5.
2013-03-06 15:11:18 +04:00
abk
a5806fd49e Input shapes were corrected by 'updatetolerance' in tests:
- bugs modalg bug697_3,
-             bug697_4,
-             bug697_7,
-             bug697_8,
-             bug697_11,
-             bug1255,
-             bug1255_1,
-             bug5729,
-             bug6181,
-             bug6182,
-             bug6272_85,
-             bug6272_86,
-             bug10842_5.
2013-03-06 15:07:17 +04:00
abk
65b387bd75 Draw command 'EnsureTolRule' was replaced by command 'updatetolerance' in
tests.

Draw command 'EnsureTolRule' was removed.
2013-03-06 15:04:42 +04:00
abk
3e9d304d46 BRepBuilderAPI_MakeShape::EnsureToleranceRule was replaced by
BRepLib::UpdateTolerances.

BRepBuilderAPI_MakeShape::EnsureToleranceRule was removed.
2013-03-06 15:04:04 +04:00
abk
916851661a Error messages was changed in test case data file chamfer/data/complex/B9. Error message was changed in test cases: - thrusection/solids/A2, - A3, - A4, - A5, - A6, - A7, - A8, - A9. 2013-03-06 14:59:46 +04:00
abk
5ed5c561b0 Error message was changed in test case data files: - heal/data/advanced/H5, - S7, - ZC3, - ZE6, - ZE8, - ZE9. Result shape in the tests is invalid. 2013-03-06 14:59:42 +04:00
abk
36228fd825 Error message was changed in test case heal/drop_small|_edges/A4. Result shape in the test is invalid. 2013-03-06 14:59:38 +04:00
abk
168b9ec45a Draw function nexplode was replaced by explode in test case
blend/complex/D4.
Calculation of gravity center was removed for degenerated edge.
It is revealed that function nexplode does not work on shapes with
degenerated edges.

Comments.
Calculation of gravity center was made by vertices data in case of
degenerated edge without representations especially for test case
blend/complex/D4. The mass of the edge was set to 1. The mass near 0 does
not satisfy the test case. As a result test case bugs/moddata/bug268
became failed. Because only the mass near 0 satisfies last test case.
2013-03-06 14:56:53 +04:00
abk
7ed3f1cf33 Error message was changed in test case heal/drop_small_edges/A4. 2013-03-06 14:56:50 +04:00
abk
c3cf76dfbd Calculation of gravity center was made by vertices data for degenerated
edge without representations.
2013-03-06 14:51:30 +04:00
abk
3d9cefa6a7 Correction of tolerances in result shape was made for group boolean and
grids:
- heal drop_small_edges,
       fix_face_size,
       fix_gaps,
       split_angle_advanced,
       surface_to_bspline.

Correction of tolerances in input shapes was made for tests:
- bugs heal bug329,
- bugs modalg buc60462_1,
              buc60463,
              bug292,
              bug317,
              bug330,
              bug452_2,
              bug452_3,
              bug625,
              bug697_1,
              bug698,
              bug774_1,
              bug776_1,
              bug776_2,
              bug80,
              bug919,
- bugs moddata buc60652_2,
               buc60652_3,
               buc60707,
               bug368,
               bug75_2,
               fra62476_2,
               ger61235,
               pro20333,
- bugs step buc60948,
- bugs step bug630,
- bugs vis buc60661,
- bugs vis bug288_1,
- bugs vis bug288_4,
- bugs xde bug859,
- bugs xde bug861,
- feat featlf B8,
       featprism L2,
                 L8,
                 M1,
                 O6,
                 O9,
                 R1,
                 S1,
                 S2,
- sewing tol_0_01 T1.
2013-03-06 14:51:27 +04:00
abk
dca967d0b8 Method BRepGProp::LinearProperties was changed to avoid degenerated edges. 2013-03-06 14:51:02 +04:00
abk
064a93b073 Method BRepBuilderAPI_MakeShape::EnsureToleranceRule was made slightly
simpler.

Tolerance post Build (Perform) fix was made for:
- BRepAlgoAPI_BooleanOperation,
- BRepFeat_MakePrism,
- BRepOffsetAPI_MakePipeShell.

Draw command getsourcefile now returns result for:
- buildsweep,
- simulsweep,
- geompipe.
2013-03-06 14:50:57 +04:00
abk
b015a803fc Application of EnsureToleranceRule to ShapeFix_Shape was fixed. 2013-03-06 14:46:41 +04:00
abk
43809f7eec Static public method EnsureToleranceRule(const TopoDS_Shape & theS) was
created in class BRepBuilderAPI_MakeShape to fix all tolerances of the
shape and it's subshapes by the tolerance rule:
vertex tolerance >= edge tolerance >= face tolerance.
Edge or vertex tolerance which does not satisfy the tolerance rule will be
increased.
Draw command EnsureTolRule was created to test new functional.
Tolerance post Build (Perform) fix was made for:
- BRepBuilderAPI_Sewing,
- BRepFilletAPI_MakeChamfer,
- BRepFilletAPI_MakeFillet,
- BRepOffsetAPI_MakePipe,
- BRepOffsetAPI_NormalProjection,
- ShapeFix_Shape,
- ShapeUpgrade_ShapeDivide.
2013-03-06 14:46:38 +04:00
abv
eeb913ae52 0023610: checkshape command does not detect mismatch of the tolerance values among the sub-shapes of the shape
In BRepCheck, added check for tolerance of face to be not greater than tolerance of edge, and tolerance of edge not greater than tolerance of its vertices
2013-03-06 14:46:35 +04:00
17779 changed files with 509053 additions and 322486 deletions

2
.gitattributes vendored
View File

@@ -12,7 +12,6 @@
*.jxx eol=lf
*.lxx eol=lf
*.pxx eol=lf
*.cl eol=lf
*.cdl eol=lf
*.edl eol=lf
*.yacc eol=lf
@@ -35,7 +34,6 @@
*.brep eol=lf
*.rle eol=lf
*.vrml eol=lf
*.md eol=lf
FILES eol=lf
PACKAGES eol=lf
EXTERNLIB eol=lf

9
.gitignore vendored
View File

@@ -7,7 +7,6 @@
/ao1
/sil
/wnt
/doc
/drv
/inc
/work
@@ -16,12 +15,6 @@
win32
win64
# standard names of directories for objects and binaries for samples
bin
obj
Debug
Release
# project files and artifacts
/adm/msvc
/adm/wnt
@@ -30,7 +23,6 @@ Release
/adm/make
/adm/cmake
*.vcproj*user
*.csproj*user
*.ncb
*.suo
*.sdf
@@ -42,6 +34,7 @@ Release
*~
#Generated files
*.in
/*.am
/*.m4
/*.ac

View File

@@ -1,503 +0,0 @@
cmake_minimum_required ( VERSION 2.6)
if (NOT BUILD_CONFIGURATION)
set(BUILD_CONFIGURATION "Release" CACHE STRING "Build type of OCCT" FORCE)
SET_PROPERTY(CACHE BUILD_CONFIGURATION PROPERTY STRINGS Release Debug RelWithDebInfo)
endif()
set(CMAKE_CONFIGURATION_TYPES ${BUILD_CONFIGURATION} CACHE INTERNAL "" FORCE)
project(OCCT)
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
set(BUILD_SHARED_LIBS ON)
IF("${BUILD_CONFIGURATION}" STREQUAL "${CMAKE_BUILD_TYPE}")
SET(CHANGES_ARE_NEEDED OFF)
ELSE()
SET(CHANGES_ARE_NEEDED ON)
ENDIF()
MATH(EXPR COMPILER_BITNESS "32 + 32*(${CMAKE_SIZEOF_VOID_P}/8)")
SET( CMAKE_BUILD_TYPE ${BUILD_CONFIGURATION} CACHE INTERNAL "Build type of OCCT" FORCE )
SET( INSTALL_DIR "" CACHE PATH "Directory that will contain install files of OCCT" )
SET( CMAKE_INSTALL_PREFIX "${INSTALL_DIR}" CACHE INTERNAL "" FORCE )
set (BUILD_TOOLKITS "" CACHE STRING "Toolkits are also included in OCCT")
separate_arguments(BUILD_TOOLKITS)
IF(MSVC)
SET(BUILD_Samples OFF CACHE BOOL "OCCT samples building")
ENDIF()
include(adm/cmake/CMakeModules.txt)
if (WIN32)
set(SCRIPT_EXT bat)
else()
set(SCRIPT_EXT sh)
endif()
if (MSVC)
add_definitions(/fp:precise)
endif()
# set compiler short name and choose SSE2 option for appropriate MSVC compilers
if (DEFINED MSVC70)
SET(COMPILER vc7)
elseif (DEFINED MSVC80)
SET(COMPILER vc8)
if (${COMPILER_BITNESS} STREQUAL 32)
add_definitions(/arch:SSE2)
endif()
elseif (DEFINED MSVC90)
SET(COMPILER vc9)
if (${COMPILER_BITNESS} STREQUAL 32)
add_definitions(/arch:SSE2)
endif()
elseif (DEFINED MSVC10)
SET(COMPILER vc10)
if (${COMPILER_BITNESS} STREQUAL 32)
add_definitions(/arch:SSE2)
endif()
elseif (DEFINED MSVC11)
SET(COMPILER vc11)
else()
SET(COMPILER ${CMAKE_GENERATOR})
endif()
if (${COMPILER_BITNESS} STREQUAL 64)
add_definitions(-D_OCC64)
endif()
add_definitions(-DCSFDB)
if(WIN32)
add_definitions(/DWNT -wd4996)
elseif(APPLE)
add_definitions(-fexceptions -fPIC -DOCC_CONVERT_SIGNALS -DHAVE_WOK_CONFIG_H -DHAVE_CONFIG_H)
else()
add_definitions(-fexceptions -fPIC -DOCC_CONVERT_SIGNALS -DHAVE_WOK_CONFIG_H -DHAVE_CONFIG_H -DLIN)
endif()
# enable structured exceptions for MSVC
string(REGEX MATCH "EHsc" ISFLAG "${CMAKE_CXX_FLAGS}")
IF(ISFLAG)
STRING(REGEX REPLACE "EHsc" "EHa" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
ELSEIF(WIN32)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -EHa")
ENDIF()
# enable parallel compilation on MSVC 9 and above
IF(WIN32)
IF(NOT DEFINED MSVC70 AND NOT DEFINED MSVC80)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -MP")
ENDIF()
ENDIF()
# increase compiler warnings level (-W4 for MSVC, -Wall for GCC)
IF(MSVC)
if(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
string(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
elseif(CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
endif()
SET(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -DNo_Exception")
SET(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -DNo_Exception")
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -DDEB")
SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -DDEB")
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/out/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/out/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/out/bin)
# RESOURCES
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/DrawResources" DESTINATION "${INSTALL_DIR}/src" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/StdResource" DESTINATION "${INSTALL_DIR}/src" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/SHMessage" DESTINATION "${INSTALL_DIR}/src" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/Textures" DESTINATION "${INSTALL_DIR}/src" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/Shaders" DESTINATION "${INSTALL_DIR}/src" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/XSMessage" DESTINATION "${INSTALL_DIR}/src" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/XSTEPResource" DESTINATION "${INSTALL_DIR}/src" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/src/XmlOcafResource" DESTINATION "${INSTALL_DIR}/src" )
install(FILES "${CMAKE_SOURCE_DIR}/src/UnitsAPI/Lexi_Expr.dat" DESTINATION "${INSTALL_DIR}/src/UnitsAPI" )
install(FILES "${CMAKE_SOURCE_DIR}/src/UnitsAPI/Units.dat" DESTINATION "${INSTALL_DIR}/src/UnitsAPI" )
install(FILES "${CMAKE_SOURCE_DIR}/src/TObj/TObj.msg" DESTINATION "${INSTALL_DIR}/src/TObj" )
IF("${BUILD_CONFIGURATION}" STREQUAL "Release")
SET(BUILD_SUFFIX "")
ELSE()
SET(BUILD_SUFFIX "") # debug == release
ENDIF()
FUNCTION(SUBDIRECTORY_NAMES MAIN_DIRECTORY RESULT)
file(GLOB SUB_ITEMS "${MAIN_DIRECTORY}/*")
foreach(ITEM ${SUB_ITEMS})
if(IS_DIRECTORY "${ITEM}")
GET_FILENAME_COMPONENT(ITEM_NAME "${ITEM}" NAME)
LIST(APPEND LOCAL_RESULT "${ITEM_NAME}")
endif()
endforeach()
set (${RESULT} ${LOCAL_RESULT} PARENT_SCOPE)
ENDFUNCTION()
FUNCTION(FIND_PRODUCT_DIR ROOT_DIR PRODUCT_NAME RESULT)
string( TOLOWER "${PRODUCT_NAME}" lower_PRODUCT_NAME )
LIST(APPEND SEARCH_TEMPLATES "${lower_PRODUCT_NAME}.*${COMPILER}.*${COMPILER_BITNESS}")
LIST(APPEND SEARCH_TEMPLATES "${lower_PRODUCT_NAME}.*[0-9.]+.*${COMPILER}.*${COMPILER_BITNESS}")
LIST(APPEND SEARCH_TEMPLATES "${lower_PRODUCT_NAME}.*[0-9.]+.*${COMPILER_BITNESS}")
LIST(APPEND SEARCH_TEMPLATES "${lower_PRODUCT_NAME}.*[0-9.]+")
LIST(APPEND SEARCH_TEMPLATES "${lower_PRODUCT_NAME}")
SUBDIRECTORY_NAMES( "${ROOT_DIR}" SUBDIR_NAME_LIST)
FOREACH( SEARCH_TEMPLATE ${SEARCH_TEMPLATES})
IF(LOCAL_RESULT)
BREAK()
ENDIF()
FOREACH(SUBDIR_NAME ${SUBDIR_NAME_LIST})
string( TOLOWER "${SUBDIR_NAME}" lower_SUBDIR_NAME )
STRING(REGEX MATCH "${SEARCH_TEMPLATE}" DUMMY_VAR "${lower_SUBDIR_NAME}")
IF(DUMMY_VAR)
LIST(APPEND LOCAL_RESULT ${SUBDIR_NAME})
ENDIF()
ENDFOREACH()
ENDFOREACH()
IF(LOCAL_RESULT)
LIST(LENGTH "${LOCAL_RESULT}" LOC_LEN)
MATH(EXPR LAST_ELEMENT_INDEX "${LOC_LEN}-1")
LIST(GET LOCAL_RESULT ${LAST_ELEMENT_INDEX} DUMMY)
SET(${RESULT} ${DUMMY} PARENT_SCOPE)
ENDIF()
ENDFUNCTION()
IF(WIN32)
SET(DLL_SO "dll")
SET(DLL_SO_FOLDER "bin")
SET(DLL_SO_PREFIX "")
ELSEIF(APPLE)
SET(DLL_SO "dylib")
SET(DLL_SO_FOLDER "lib")
SET(DLL_SO_PREFIX "lib")
ELSE()
SET(DLL_SO "so")
SET(DLL_SO_FOLDER "lib")
SET(DLL_SO_PREFIX "lib")
ENDIF()
SET(3RDPARTY_DIR ${CMAKE_SOURCE_DIR} CACHE PATH "Directory contains required 3rdparty products")
SET(3RDPARTY_INCLUDE_DIRS "")
SET(3RDPARTY_NOT_INCLUDED)
IF(APPLE)
SET(USE_GLX OFF CACHE BOOL "whether use X11 OpenGL on OSX or not")
ENDIF()
SET(USE_GL2PS OFF CACHE BOOL "whether use gl2ps product or not")
SET(USE_FREEIMAGE OFF CACHE BOOL "whether use freeimage product or not")
SET(USE_TBB OFF CACHE BOOL "whether use tbb product or not")
SET(USE_OPENCL OFF CACHE BOOL "whether use OpenCL or not")
SET(INSTALL_TESTS OFF CACHE BOOL "Is tests copy to install directory")
MACRO(THIRDPARTY_PRODUCT PRODUCT_NAME HEADER_NAME LIBRARY_NAME)
IF(NOT DEFINED 3RDPARTY_${PRODUCT_NAME}_DIR)
SET(3RDPARTY_${PRODUCT_NAME}_DIR "" CACHE PATH "Directory contains ${PRODUCT_NAME} product")
ENDIF()
IF(3RDPARTY_DIR AND ("${3RDPARTY_${PRODUCT_NAME}_DIR}" STREQUAL "" OR CHANGES_ARE_NEEDED))
FIND_PRODUCT_DIR("${3RDPARTY_DIR}" ${PRODUCT_NAME} ${PRODUCT_NAME}_DIR_NAME)
IF("${${PRODUCT_NAME}_DIR_NAME}" STREQUAL "")
MESSAGE(STATUS "${PRODUCT_NAME} DON'T FIND")
ELSE()
SET(3RDPARTY_${PRODUCT_NAME}_DIR "${3RDPARTY_DIR}/${${PRODUCT_NAME}_DIR_NAME}" CACHE PATH "Directory contains ${PRODUCT_NAME} product" FORCE)
ENDIF()
ENDIF()
SET(INSTALL_${PRODUCT_NAME} OFF CACHE BOOL "Is ${PRODUCT_NAME} lib copy to install directory")
IF(3RDPARTY_${PRODUCT_NAME}_DIR)
IF("${3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR}" STREQUAL "3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR-NOTFOUND")
SET(3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR "3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR-NOTFOUND" CACHE FILEPATH "Directory contains headers of the ${PRODUCT_NAME} product" FORCE)
FIND_PATH(3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR ${HEADER_NAME} PATHS "${3RDPARTY_${PRODUCT_NAME}_DIR}/include" NO_DEFAULT_PATH)
ENDIF()
IF("${3RDPARTY_${PRODUCT_NAME}_LIBRARY}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_${PRODUCT_NAME}_LIBRARY}" STREQUAL "3RDPARTY_${PRODUCT_NAME}_LIBRARY-NOTFOUND")
SET(3RDPARTY_${PRODUCT_NAME}_LIBRARY "3RDPARTY_${PRODUCT_NAME}_LIBRARY-NOTFOUND" CACHE FILEPATH "Path to library of the ${PRODUCT_NAME} product" FORCE)
FIND_LIBRARY(3RDPARTY_${PRODUCT_NAME}_LIBRARY ${LIBRARY_NAME} PATHS "${3RDPARTY_${PRODUCT_NAME}_DIR}/lib" NO_DEFAULT_PATH)
ENDIF()
IF("${3RDPARTY_${PRODUCT_NAME}_DLL}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_${PRODUCT_NAME}_DLL}" STREQUAL "3RDPARTY_${PRODUCT_NAME}_DLL-NOTFOUND")
SET(3RDPARTY_${PRODUCT_NAME}_DLL "3RDPARTY_${PRODUCT_NAME}_DLL-NOTFOUND" CACHE FILEPATH "Path to shared library of the ${PRODUCT_NAME} product" FORCE)
FIND_FILE(3RDPARTY_${PRODUCT_NAME}_DLL "${DLL_SO_PREFIX}${LIBRARY_NAME}.${DLL_SO}" PATHS "${3RDPARTY_${PRODUCT_NAME}_DIR}/${DLL_SO_FOLDER}" NO_DEFAULT_PATH)
ENDIF()
MARK_AS_ADVANCED(3RDPARTY_${PRODUCT_NAME}_DIR)
ELSE()
ENDIF()
# check default path (with additions) for header search
IF("${3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR}" STREQUAL "" OR "${3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR}" STREQUAL "3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR-NOTFOUND")
SET(3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR "3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR-NOTFOUND" CACHE FILEPATH "Directory contains headers of the ${PRODUCT_NAME} product" FORCE)
FIND_PATH(3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR ${HEADER_NAME} ${3RDPARTY_${PRODUCT_NAME}_ADDITIONAL_PATH_FOR_HEADER})
ENDIF()
# check default path (with additions) for library search
IF("${3RDPARTY_${PRODUCT_NAME}_LIBRARY}" STREQUAL "" OR "${3RDPARTY_${PRODUCT_NAME}_LIBRARY}" STREQUAL "3RDPARTY_${PRODUCT_NAME}_LIBRARY-NOTFOUND")
SET(3RDPARTY_${PRODUCT_NAME}_LIBRARY "3RDPARTY_${PRODUCT_NAME}_LIBRARY-NOTFOUND" CACHE FILEPATH "Directory contains library of the ${PRODUCT_NAME} product" FORCE)
FIND_LIBRARY(3RDPARTY_${PRODUCT_NAME}_LIBRARY ${LIBRARY_NAME} ${3RDPARTY_${PRODUCT_NAME}_ADDITIONAL_PATH_FOR_LIB})
ENDIF()
# check default path (with additions) for DLL search
IF("${3RDPARTY_${PRODUCT_NAME}_DLL}" STREQUAL "" OR "${3RDPARTY_${PRODUCT_NAME}_DLL}" STREQUAL "3RDPARTY_${PRODUCT_NAME}_DLL-NOTFOUND")
SET(3RDPARTY_${PRODUCT_NAME}_DLL "3RDPARTY_${PRODUCT_NAME}_DLL-NOTFOUND" CACHE FILEPATH "Directory contains shared library of the ${PRODUCT_NAME} product" FORCE)
FIND_FILE(3RDPARTY_${PRODUCT_NAME}_DLL "${DLL_SO_PREFIX}${LIBRARY_NAME}.${DLL_SO}" ${3RDPARTY_${PRODUCT_NAME}_ADDITIONAL_PATH_FOR_DLL})
ENDIF()
IF(3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR)
SET(3RDPARTY_INCLUDE_DIRS "${3RDPARTY_INCLUDE_DIRS};${3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR}")
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR)
ENDIF()
IF(3RDPARTY_${PRODUCT_NAME}_LIBRARY)
GET_FILENAME_COMPONENT(3RDPARTY_${PRODUCT_NAME}_LIBRARY_DIR "${3RDPARTY_${PRODUCT_NAME}_LIBRARY}" PATH)
SET(3RDPARTY_LIBRARY_DIRS "${3RDPARTY_LIBRARY_DIRS};${3RDPARTY_${PRODUCT_NAME}_LIBRARY_DIR}")
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_${PRODUCT_NAME}_LIBRARY)
ENDIF()
IF(3RDPARTY_${PRODUCT_NAME}_DLL)
#
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_${PRODUCT_NAME}_DLL)
ENDIF()
IF(INSTALL_${PRODUCT_NAME})
INSTALL(FILES "${3RDPARTY_${PRODUCT_NAME}_DLL}" DESTINATION "${INSTALL_DIR}/${DLL_SO_FOLDER}")
SET(3RDPARTY_${PRODUCT_NAME}_DLL_DIR "")
ELSE()
GET_FILENAME_COMPONENT(3RDPARTY_${PRODUCT_NAME}_DLL_DIR "${3RDPARTY_${PRODUCT_NAME}_DLL}" PATH)
ENDIF()
ENDMACRO()
# TCL
INCLUDE(adm/templates/tcl.cmake)
#install tcltk
IF(INSTALL_TCL)
SET(3RDPARTY_TCL_DLL_DIR "")
SET(3RDPARTY_TCL_LIB_DIR "")
GET_FILENAME_COMPONENT(3RDPARTY_TCL_LIB_DIR_INSIDE "${3RDPARTY_TCL_LIBRARY}" PATH)
GET_FILENAME_COMPONENT(3RDPARTY_TCL_DLL_DIR_INSIDE "${3RDPARTY_TCL_DLL}" PATH)
IF (IS_TCL_VERSION_FOUND)
SET (TCL_VERSION ${TCL_MAJOR_VERSION}${TCL_SEP}${TCL_MINOR_VERSION})
SET (TCL_FOLDER_VERSION ${TCL_MAJOR_VERSION}.${TCL_MINOR_VERSION})
ELSE()
SET (TCL_VERSION "")
#TODO SEARCH tclX.X & tkX.X subdirs
SET (TCL_FOLDER_VERSION "")
ENDIF()
INSTALL(FILES "${3RDPARTY_TCL_DLL_DIR_INSIDE}/${DLL_SO_PREFIX}tcl${TCL_VERSION}.${DLL_SO}" DESTINATION "${INSTALL_DIR}/${DLL_SO_FOLDER}")
INSTALL(FILES "${3RDPARTY_TCL_DLL_DIR_INSIDE}/${DLL_SO_PREFIX}tk${TCL_VERSION}.${DLL_SO}" DESTINATION "${INSTALL_DIR}/${DLL_SO_FOLDER}")
IF (IS_TCL_VERSION_FOUND)
INSTALL(DIRECTORY "${3RDPARTY_TCL_LIB_DIR_INSIDE}/tcl8" DESTINATION "${INSTALL_DIR}/lib")
INSTALL(DIRECTORY "${3RDPARTY_TCL_LIB_DIR_INSIDE}/tcl${TCL_FOLDER_VERSION}" DESTINATION "${INSTALL_DIR}/lib")
INSTALL(DIRECTORY "${3RDPARTY_TCL_LIB_DIR_INSIDE}/tk${TCL_FOLDER_VERSION}" DESTINATION "${INSTALL_DIR}/lib")
ELSE()
MESSAGE(STATUS "\nWarning: tclX.X and tkX.X subdirs won't be copyied during the installation process.")
MESSAGE(STATUS "Try seeking tcl within another folder by changing 3RDPARTY_TCL_DIR variable.")
ENDIF()
ELSE()
GET_FILENAME_COMPONENT(3RDPARTY_TCL_DLL_DIR "${3RDPARTY_TCL_DLL}" PATH)
GET_FILENAME_COMPONENT(3RDPARTY_TCL_LIB_DIR "${3RDPARTY_TCL_LIBRARY}" PATH)
ENDIF()
# GLX
IF(USE_GLX)
ADD_DEFINITIONS(-DMACOSX_USE_GLX)
IF(NOT DEFINED 3RDPARTY_GLX_DIR)
SET(3RDPARTY_GLX_DIR "" CACHE PATH "Directory contains GLX product")
ENDIF()
IF(3RDPARTY_DIR AND ("${3RDPARTY_GLX_DIR}" STREQUAL "" OR CHANGES_ARE_NEEDED))
FIND_PRODUCT_DIR("${3RDPARTY_DIR}" GLX GLX_DIR_NAME)
IF("${GLX_DIR_NAME}" STREQUAL "")
MESSAGE(STATUS "GLX DON'T FIND")
ELSE()
SET(3RDPARTY_GLX_DIR "${3RDPARTY_DIR}/${GLX_DIR_NAME}" CACHE PATH "Directory contains GLX product" FORCE)
ENDIF()
ENDIF()
IF(3RDPARTY_GLX_DIR)
SET(3RDPARTY_GLX_INCLUDE_DIR "${3RDPARTY_GLX_DIR}/include" CACHE FILEPATH "Directory contains headers of the GLX product" FORCE)
SET(3RDPARTY_GLX_LIBRARY_DIR "${3RDPARTY_GLX_DIR}/lib" CACHE FILEPATH "Directory contains library of the GLX product" FORCE)
SET(3RDPARTY_INCLUDE_DIRS "${3RDPARTY_INCLUDE_DIRS};${3RDPARTY_GLX_INCLUDE_DIR}")
SET(3RDPARTY_LIBRARY_DIRS "${3RDPARTY_LIBRARY_DIRS};${3RDPARTY_GLX_LIBRARY_DIR}")
MARK_AS_ADVANCED(3RDPARTY_GLX_DIR)
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_GLX_INCLUDE_DIR)
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_GLX_LIBRARY_DIR)
ENDIF()
ENDIF()
# FREETYPE
THIRDPARTY_PRODUCT("FREETYPE" "ft2build.h" "freetype${BUILD_SUFFIX}")
IF("${3RDPARTY_FREETYPE_INCLUDE_DIR}" STREQUAL "" OR "${3RDPARTY_FREETYPE_INCLUDE_DIR}" STREQUAL "3RDPARTY_${PRODUCT_NAME}_INCLUDE_DIR-NOTFOUND")
ELSEIF(EXISTS "${3RDPARTY_FREETYPE_INCLUDE_DIR}/freetype2/")
SET(3RDPARTY_INCLUDE_DIRS "${3RDPARTY_INCLUDE_DIRS};${3RDPARTY_FREETYPE_INCLUDE_DIR}/freetype2")
ENDIF()
# FREEIMAGE
IF(USE_FREEIMAGE)
ADD_DEFINITIONS(-DHAVE_FREEIMAGE)
THIRDPARTY_PRODUCT("FREEIMAGE" "FreeImage.h" "freeimage${BUILD_SUFFIX}")
IF(WIN32)
IF("${3RDPARTY_FREEIMAGE_DIR}" STREQUAL "")
ELSE()
SET (3RDPARTY_FREEIMAGEPLUS_DIR "${3RDPARTY_FREEIMAGE_DIR}")
ENDIF()
THIRDPARTY_PRODUCT("FREEIMAGEPLUS" "FreeImagePlus.h" "freeimageplus${BUILD_SUFFIX}")
ENDIF()
ENDIF()
# GL2PS
IF(USE_GL2PS)
ADD_DEFINITIONS(-DHAVE_GL2PS)
THIRDPARTY_PRODUCT("GL2PS" "gl2ps.h" "gl2ps${BUILD_SUFFIX}")
ENDIF()
# OPENCL
IF(USE_OPENCL)
ADD_DEFINITIONS(-DHAVE_OPENCL)
SET (3RDPARTY_OPENCL_ADDITIONAL_PATH_FOR_HEADER $ENV{AMDAPPSDKROOT}/include
$ENV{INTELOCLSDKROOT}/include
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/inc
$ENV{ATISTREAMSDKROOT}/include)
IF(${COMPILER_BITNESS} STREQUAL 32)
SET (3RDPARTY_OPENCL_ADDITIONAL_PATH_FOR_LIB $ENV{AMDAPPSDKROOT}/lib/x86
$ENV{INTELOCLSDKROOT}/lib/x86
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/lib/Win32
$ENV{ATISTREAMSDKROOT}/lib/x86)
ELSEIF(${COMPILER_BITNESS} STREQUAL 64)
SET (3RDPARTY_OPENCL_ADDITIONAL_PATH_FOR_LIB $ENV{AMDAPPSDKROOT}/lib/x86_64
$ENV{INTELOCLSDKROOT}/lib/x64
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/lib/x64
$ENV{ATISTREAMSDKROOT}/lib/x86_64)
ENDIF()
THIRDPARTY_PRODUCT("OPENCL" "CL/cl.h" "OpenCL${BUILD_SUFFIX}")
# if CL/cl.h isn't found (and 3RDPARTY_OPENCL_INCLUDE_DIR isn't defined)
# then try to find OpenCL/cl.h (all other variable won't be changed)
THIRDPARTY_PRODUCT("OPENCL" "OpenCL/cl.h" "OpenCL${BUILD_SUFFIX}")
ENDIF()
# TBB
IF (USE_TBB)
ADD_DEFINITIONS(-DHAVE_TBB)
INCLUDE(adm/templates/tbb.cmake)
IF(INSTALL_TBB)
INSTALL(FILES "${3RDPARTY_TBB_DLL}" "${3RDPARTY_TBB_MALLOC_DLL}" DESTINATION "${INSTALL_DIR}/${DLL_SO_FOLDER}")
SET(3RDPARTY_TBB_DLL_DIR "")
SET(3RDPARTY_TBB_MALLOC_DLL_DIR "")
ELSE()
GET_FILENAME_COMPONENT(3RDPARTY_TBB_DLL_DIR "${3RDPARTY_TBB_DLL}" PATH)
GET_FILENAME_COMPONENT(3RDPARTY_TBB_MALLOC_DLL_DIR "${3RDPARTY_TBB_MALLOC_DLL}" PATH)
ENDIF()
ENDIF()
string( REGEX REPLACE ";" " " 3RDPARTY_NOT_INCLUDED "${3RDPARTY_NOT_INCLUDED}")
#CHECK ALL 3RDPARTY PATHS
IF(3RDPARTY_NOT_INCLUDED)
MESSAGE(FATAL_ERROR "NOT FOUND: ${3RDPARTY_NOT_INCLUDED}" )
ENDIF()
list(REMOVE_DUPLICATES 3RDPARTY_INCLUDE_DIRS)
string( REGEX REPLACE ";" "\n\t" 3RDPARTY_INCLUDE_DIRS_WITH_ENDS "${3RDPARTY_INCLUDE_DIRS}")
MESSAGE(STATUS "3RDPARTY_INCLUDE_DIRS: ${3RDPARTY_INCLUDE_DIRS_WITH_ENDS}")
include_directories( ${3RDPARTY_INCLUDE_DIRS} )
list(REMOVE_DUPLICATES 3RDPARTY_LIBRARY_DIRS)
string( REGEX REPLACE ";" "\n\t" 3RDPARTY_LIBRARY_DIRS_WITH_ENDS "${3RDPARTY_LIBRARY_DIRS}")
MESSAGE(STATUS "3RDPARTY_LIBRARY_DIRS: ${3RDPARTY_LIBRARY_DIRS_WITH_ENDS}")
link_directories( ${3RDPARTY_LIBRARY_DIRS} )
IF("${INSTALL_DIR}" STREQUAL "")
MESSAGE(FATAL_ERROR "INSTALL_DIR is empty")
ELSE()
# inc,data,tests DIRECTORY
install(DIRECTORY "${CMAKE_SOURCE_DIR}/inc" DESTINATION "${INSTALL_DIR}" )
install(DIRECTORY "${CMAKE_SOURCE_DIR}/data" DESTINATION "${INSTALL_DIR}" )
IF(INSTALL_TESTS)
install(DIRECTORY "${CMAKE_SOURCE_DIR}/tests" DESTINATION "${INSTALL_DIR}" )
ENDIF()
# DRAW.BAT or DRAW.SH
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)
IF (BUILD_Samples)
install(FILES "${CMAKE_SOURCE_DIR}/adm/templates/sample.bat" DESTINATION "${INSTALL_DIR}")
ENDIF()
configure_file("${CMAKE_SOURCE_DIR}/adm/templates/env.${SCRIPT_EXT}.in" env.${SCRIPT_EXT} @ONLY)
install(FILES "${OCCT_BINARY_DIR}/env.${SCRIPT_EXT}" DESTINATION "${INSTALL_DIR}" )
ENDIF()
include(adm/cmake/CMakeToolKitsDeps.txt)
IF (BUILD_Samples)
SET (CMAKE_MFC_FLAG 2)
SET (OCCT_ROOT ${CMAKE_SOURCE_DIR})
SET (MFC_STANDARD_SAMPLES_DIR ${OCCT_ROOT}/samples/mfc/standard)
SET (COMMON_WINMAIN_FILE ${MFC_STANDARD_SAMPLES_DIR}/Common/Winmain.cpp)
subdirs(samples/mfc/standard/mfcsample)
subdirs(samples/mfc/standard/01_Geometry)
subdirs(samples/mfc/standard/02_Modeling)
subdirs(samples/mfc/standard/03_Viewer2d)
subdirs(samples/mfc/standard/04_Viewer3d)
subdirs(samples/mfc/standard/05_ImportExport)
subdirs(samples/mfc/standard/06_Ocaf)
subdirs(samples/mfc/standard/07_Triangulation)
subdirs(samples/mfc/standard/08_HLR)
subdirs(samples/mfc/standard/09_Animation)
subdirs(samples/mfc/standard/10_Convert)
ENDIF()

151
LICENSE Normal file
View File

@@ -0,0 +1,151 @@
Open CASCADE Technology Public License
License version: 6.5 March, 2011
Open CASCADE S.A.S. releases and makes publicly available the source code of the software Open CASCADE Technology to the free software development community under the terms and conditions of this license.
It is not the purpose of this license to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this license has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
Please read this license carefully and completely before downloading this software. By downloading, using, modifying, distributing and sublicensing this software, you indicate your acceptance to be bound by the terms and conditions of this license. If you do not want to accept or cannot accept for any reasons the terms and conditions of this license, please do not download or use in any manner this software.
1. Definitions
Unless there is something in the subject matter or in the context inconsistent therewith, the capitalized terms used in this License shall have the following meaning.
"Applicable Intellectual Property Rights" means (a) with respect to the Initial Developer, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to the Initial Developer and that cover subject matter contained in the Original Code, but only to the extent necessary to use, reproduce, modify, distribute or sublicense the Original Code without infringement; and (b) with respect to You or any Contributor, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to You or to such Contributor and that cover subject matter contained in Your Modifications or in such Contributor's Modifications, taken alone or in combination with Original Code.
"Contributor" means each individual or legal entity that creates or contributes to the creation of any Modification, including the Initial Developer.
"Derivative Program": means a new program combining the Software or portions thereof with other source code not governed by the terms of this License.
"Initial Developer": means Open CASCADE S.A.S., with main offices at 1, place des Fr<46>res Montgolfier, 78280 Guyancourt, France.
"Modifications": mean any addition to, deletion from or change to the substance or the structure of the Software. When source code of the Software is released as a series of files, a Modification is: (a) any addition to, deletion from or change to the contents of a file containing the Software or (b) any new file or other representation of computer program statements that contains any part of the Software. By way of example, Modifications include any debug of, or improvement to, the Original Code or any of its components or portions as well as its next versions or releases thereof.
"Original Code": means (a) the source code of the software Open CASCADE Technology originally made available by the Initial Developer under this License, including the source code of any updates or upgrades of the Original Code and (b) the object code compiled from such source code and originally made available by Initial Developer under this License.
"Software": means the Original Code, the Modifications, the combination of Original Code and any Modifications or any respective portions thereof.
"You" or "Your": means an individual or a legal entity exercising rights under this License.
2. Acceptance of license
By using, reproducing, modifying, distributing or sublicensing the Software or any portion thereof, You expressly indicate Your acceptance of the terms and conditions of this License and undertake to act in accordance with all the provisions of this License applicable to You.
3. Scope and purpose
This License applies to the Software and You may not use, reproduce, modify, distribute, sublicense or circulate the Software, or any portion thereof, except as expressly provided under this License. Any attempt to otherwise use, reproduce, modify, distribute or sublicense the Software is void and will automatically terminate Your rights under this License.
4. Contributor license
Subject to the terms and conditions of this License, the Initial Developer and each of the Contributors hereby grant You a world-wide, royalty-free, irrevocable and non-exclusive license under the Applicable Intellectual Property Rights they own or control, to use, reproduce, modify, distribute and sublicense the Software provided that:
You reproduce in all copies of the Software the copyright and other proprietary notices and disclaimers of the Initial Developer as they appear in the Original Code and attached hereto as Schedule "A" and any other notices or disclaimers attached to the Software and keep intact all notices in the Original Code that refer to this License and to the absence of any warranty;
You include a copy of this License with every copy of the Software You distribute;
If you distribute or sublicense the Software (as modified by You or on Your behalf as the case may be), You cause such Software to be licensed as a whole, at no charge, to all third parties, under the terms and conditions of the License, making in particular available to all third parties the source code of the Software;
You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used, prominently include a file carrying such information with respect to the Modifications and duplicate the copyright and other proprietary notices and disclaimers attached hereto as Schedule "B" or any other notices or disclaimers attached to the Software with your Modifications.
For greater certainty, it is expressly understood that You may freely create Derivative Programs (without any obligation to publish such Derivative Program) and distribute same as a single product. In such case, You must ensure that all the requirements of this License are fulfilled for the Software or any portion thereof.
5. Your license
You hereby grant all Contributors and anyone who becomes a party under this License a world-wide, non-exclusive, royalty-free and irrevocable license under the Applicable Intellectual Property Rights owned or controlled by You, to use, reproduce, modify, distribute and sublicense all Your Modifications under the terms and conditions of this License.
6. Software subject to license
Your Modifications shall be governed by the terms and conditions of this License. You are not authorized to impose any other terms or conditions than those prevailing under this License when You distribute and/or sublicense the Software, save and except as permitted under Section 7 hereof.
7. Additional terms
You may choose to offer, on a non-exclusive basis, and to charge a fee for any warranty, support, maintenance, liability obligations or other rights consistent with the scope of this License with respect to the Software (the "Additional Terms") to the recipients of the Software. However, You may do so only on Your own behalf and on Your sole and exclusive responsibility. You must obtain the recipient's agreement that any such Additional Terms are offered by You alone, and You hereby agree to indemnify, defend and hold the Initial Developer and any Contributor harmless for any liability incurred by or claims asserted against the Initial Developer or any Contributors with respect to any such Additional Terms.
8. Disclaimer of warranty
The Software is provided under this License on an "as is" basis, without warranty of any kind, including without limitation, warranties that the Software is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the Software is with You.
9. Liability
Under no circumstances shall You, the Initial Developer or any Contributor be liable to any person for any direct or indirect damages of any kind including, without limitation, damages for loss of goodwill, loss of data, work stoppage, computer failure or malfunction or any and all other commercial damages or losses resulting from or relating to this License or indirectly to the use of the Software.
10. Trademark
This License does not grant any rights to use the trademarks, trade names and domain names "MATRA", "EADS Matra Datavision", "CAS.CADE", "Open CASCADE", "opencascade.com" and "opencascade.org" or any other trademarks, trade names or domain names used or owned by the Initial Developer.
11. Copyright
The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright <20> notice which appears when You download the Software.
12. Term
This License is granted to You for a term equal to the remaining period of protection covered by the intellectual property rights applicable to the Original Code.
13. Termination
In case of termination, as provided in Section 3 above, You agree to immediately stop any further use, reproduction, modification, distribution and sublicensing of the Software and to destroy all copies of the Software that are in Your possession or control. All sublicenses of the Software which have been properly granted prior to termination shall survive any termination of this License. In addition, Sections 5, 8 to 11, 13.2 and 15.2 of this License, in reason of their nature, shall survive the termination of this License for a period of fifteen (15) years.
14. Versions of the license
The Initial Developer may publish new versions of this License from time to time. Once Original Code has been published under a particular version of this License, You may choose to continue to use it under the terms and conditions of that version or use the Original Code under the terms of any subsequent version of this License published by the Initial Developer.
15. Miscellaneous
15.1 Relationship of Parties
This License will not be construed as creating an agency, partnership, joint venture or any other form of legal association between You and the Initial Developer, and You will not represent to the contrary, whether expressly, by implication or otherwise.
15.2 Independent Development
Nothing in this License will impair the Initial Developer's right to acquire, license, develop, have others develop for it, market or distribute technology or products that perform the same or similar functions as, or otherwise compete with, Modifications, Derivative Programs, technology or products that You may develop, produce, market or distribute.
15.3 Severability
If for any reason a court of competent jurisdiction finds any provision of this License, or portion thereof, to be unenforceable, that provision of the License will be enforced to the maximum extent permissible so as to effect the economic benefits and intent of the parties, and the remainder of this License will continue in full force and extent.
END OF THE TERMS AND
CONDITIONS OF THIS LICENSE
Open CASCADE S.A.S. is a French soci<63>t<EFBFBD> par actions simplifi<66>e having its main offices at 1, place des Fr<46>res Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address www.opencascade.com
Open CASCADE Technology Public License
Schedule "A"
The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file.
The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Fr<46>res Montgolfier, 78280 Guyancourt, France. The Original Code is copyright <20> Open CASCADE S.A.S., 2001. All rights reserved.
"The Original Code and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement. Please see the License for the specific terms and conditions governing rights and limitations under the License".
End of Schedule "A"
Open CASCADE Technology Public License
Schedule "B"
"The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file.
The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Fr<46>res Montgolfier, 78280 Guyancourt, France. The Original Code is copyright <20> Open CASCADE S.A.S., 2001. All rights reserved.
Modifications to the Original Code have been made by ________________________. Modifications are copyright <20> [Year to be included]. All rights reserved.
The software Open CASCADE Technology and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement. Please see the License for the specific terms and conditions governing rights and limitations under the License".
End of Schedule "B"

View File

@@ -1,502 +0,0 @@
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts
as the successor of the GNU Library Public License, version 2, hence
the version number 2.1.]
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some
specially designated software packages--typically libraries--of the
Free Software Foundation and other authors who decide to use it. You
can use it too, but we suggest you first think carefully about whether
this license or the ordinary General Public License is the better
strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use,
not price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and charge
for this service if you wish); that you receive source code or can get
it if you want it; that you can change the software and use pieces of
it in new free programs; and that you are informed that you can do
these things.
To protect your rights, we need to make restrictions that forbid
distributors to deny you these rights or to ask you to surrender these
rights. These restrictions translate to certain responsibilities for
you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it. And you must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the
library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that
there is no warranty for the free library. Also, if the library is
modified by someone else and passed on, the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others.
Finally, software patents pose a constant threat to the existence of
any free program. We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a
restrictive license from a patent holder. Therefore, we insist that
any patent license obtained for a version of the library must be
consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License. This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License. We use
this license for certain libraries in order to permit linking those
libraries into non-free programs.
When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. The Lesser General
Public License permits more lax criteria for linking other code with
the library.
We call this license the "Lesser" General Public License because it
does Less to protect the user's freedom than the ordinary General
Public License. It also provides other free software developers Less
of an advantage over competing non-free programs. These disadvantages
are the reason we use the ordinary General Public License for many
libraries. However, the Lesser license provides advantages in certain
special circumstances.
For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it becomes
a de-facto standard. To achieve this, non-free programs must be
allowed to use the library. A more frequent case is that a free
library does the same job as widely used non-free libraries. In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software. For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.
Although the Lesser General Public License is Less protective of the
users' freedom, it does ensure that the user of a program that is
linked with the Library has the freedom and the wherewithal to run
that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, whereas the latter must
be combined with the library in order to run.
GNU LESSER GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library or other
program which contains a notice placed by the copyright holder or
other authorized party saying it may be distributed under the terms of
this Lesser General Public License (also called "this License").
Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. (Hereinafter, translation is
included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact
all the notices that refer to this License and to the absence of any
warranty; and distribute a copy of this License along with the
Library.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices
stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a
table of data to be supplied by an application program that uses
the facility, other than as an argument passed when the facility
is invoked, then you must make a good faith effort to ensure that,
in the event an application does not supply such function or
table, the facility still operates, and performs whatever part of
its purpose remains meaningful.
(For example, a function in a library to compute square roots has
a purpose that is entirely well-defined independent of the
application. Therefore, Subsection 2d requires that any
application-supplied function or table used by this function must
be optional: if the application does not supply it, the square
root function must still compute square roots.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Library,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Library, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Library.
In addition, mere aggregation of another work not based on the Library
with the Library (or with a work based on the Library) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you accompany
it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange.
If distribution of object code is made by offering access to copy
from a designated place, then offering equivalent access to copy the
source code from the same place satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library
facilities. This must be distributed under the terms of the
Sections above.
b) Give prominent notice with the combined library of the fact
that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate your
rights under this License. However, parties who have received copies,
or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all. For example, if a patent
license would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any
particular circumstance, the balance of the section is intended to apply,
and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Library under this License may add
an explicit geographical distribution limitation excluding those countries,
so that distribution is permitted only in or among countries not thus
excluded. In such case, this License incorporates the limitation as if
written in the body of this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation. If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting
redistribution under these terms (or, alternatively, under the terms of the
ordinary General Public License).
To apply these terms, attach the following notices to the library. It is
safest to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
<one line to give the library's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the
library `Frob' (a library for tweaking knobs) written by James Random Hacker.
<signature of Ty Coon>, 1 April 1990
Ty Coon, President of Vice
That's all there is to it!

View File

@@ -1,10 +0,0 @@
Open CASCADE exception (version 1.0) to GNU LGPL version 2.1.
The object code (i.e. not a source) form of a "work that uses the Library"
can incorporate material from a header file that is part of the Library.
As a special exception to the GNU Lesser General Public License version 2.1,
you may distribute such object code incorporating material from header files
provided with the Open CASCADE Technology libraries (including code of CDL
generic classes) under terms of your choice, provided that you give
prominent notice in supporting documentation to this code that it makes use
of or is based on facilities provided by the Open CASCADE Technology software.

44
README Normal file
View File

@@ -0,0 +1,44 @@
Open CASCADE Technology source repository
-----------------------------------------
This directory contains sources of Open CASCADE Technology (OCCT), a collection
of C++ libraries providing services for 3D surface and solid modeling, CAD data
exchange, and visualization. OCCT can be best applied in development of
software dealing with 3D modeling (CAD), manufacturing / measuring (CAM) or
numerical simulation (CAE).
The OCCT code is subject to the Open CASCADE Technology Public License Version
6.5 (the "License"). You may not use the content of the relevant files except in
compliance with the License. Please see the LICENSE file or obtain a copy of the
License at http://www.opencascade.org and read it completely before using this
software.
In order to build OCCT libraries from these sources for use in your program,
you need to:
1. Download, build, and install the required third-party libraries.
Follow the instructions provided in the documents titled "Building 3rd party
products for OCCT" on http://dev.opencascade.org/?q=home/resources for
installation and building.
2. Install and configure WOK development environment.
See http://dev.opencascade.org/?q=home/resources for the latest build of the
WOK and instructions of configuring it.
3. Use WOK to generate build scripts or project files for your compiler,
then build the libraries.
Note that you may use also the pre-processed source packages that include
makefiles and projects, or binary packages, available for official releases of
OCCT at http://www.opencascade.org. In this case however you will not be able
to re-generate derived files after changing the CDL files (requires WOK).
The current version of OCCT can be consulted in the file
src/Standard/Standard_Version.hxx
For more information regarding OCCT code development please consult the official
OCCT Collaborative Development Portal:
http://dev.opencascade.org

View File

@@ -1,90 +0,0 @@
Open CASCADE Technology
=======================
This directory contains sources of Open CASCADE Technology (OCCT), a software
development platform providing services for 3D surface and solid modeling, CAD
data exchange, and visualization. Most of OCCT functionality is available in
the form of C++ libraries. OCCT can be best applied in development of software
dealing with 3D modeling (CAD), manufacturing / measuring (CAM) or numerical
simulation (CAE).
License
-------
Open CASCADE Technology is free software; you can redistribute it and / or
modify it under the terms of the GNU Lesser General Public version 2.1 as
published by the Free Software Foundation, with special exception defined in
the file OCCT_LGPL_EXCEPTION.txt. Consult the file LICENSE_LGPL_21.txt included
in OCCT distribution for complete text of the license.
Alternatively, Open CASCADE Technology may be used under the terms of Open
CASCADE commercial license or contractual agreement.
Note that Open CASCADE Technology is provided on an "AS IS" basis, WITHOUT
WARRANTY OF ANY KIND. The entire risk related to any use of the OCCT code and
materials is on you. See the license text for formal disclaimer.
Packaging
---------
You can receive certified version of OCCT code in different packages.
- Snapshot of Git repository: contains only bare sources of OCCT; many C++
files, HTML documentation, and project files / makefiles for building OCCT
need to be generated.
- Complete source archive: contains all sources of OCCT, including C++ files
generated by WOK, HTML and PDF documentation, and projects / makefiles for
building on all officially supported platforms.
- Binary package (platform-specific): in addition to complete source archive,
it includes binaries of OCCT and third-party libraries built on one platform.
This package allows using OCCT immediately after installation.
Certified versions of OCCT can be downloaded from http://www.opencascade.org
You can also find OCCT pre-installed on your system, or install it from
packages provided by a third party. Note that packaging and functionality
of such versions can be different from certified releases. Please consult
documentation accompanyog your version for details.
Documentation
-------------
Open file doc/html/index.html to browse HTML documentation.
If HTML documentation is not available in your package, you can:
- Generate it from sources.
You need to have Tcl and Doxygen 1.8.4 (or above) installed on your system.
and accessible in your environment (check environment variable PATH).
Run batch file *gendoc.bat* on Windows or Bash scriot *gendoc.sh* on Linux
or Mac OS X to (re)generate documentation.
- Read documentation in source plain text (MarkDown) format found in
subfolder *dox*
See *dox/dev_guides/documentation/documentation.md* for details.
Building
--------
In most cases you need to rebuild OCCT on your platform (OS, compiler) before
using it in your project, to ensure binary compatibility.
Consult the file *dox/dev_guides/building/building.md* for instructions on
building OCCT from sources on supported platforms.
Version
-------
The current version of OCCT can be consulted in the file
*src/Standard/Standard_Version.hxx*
Development
-----------
For information regarding OCCT code development please consult the official
OCCT Collaborative Development Portal:
http://dev.opencascade.org

View File

@@ -146,7 +146,6 @@ p GeomPlate
p HLRAlgo
p HLRBRep
p HLRTopoBRep
p HLRAppli
p Hatch
p HatchGen
p IntCurve
@@ -206,10 +205,12 @@ t TKTopAlgo
t TKXMesh
n InterfaceGraphic
p AIS
p AlienImage
p Aspect
p DsgPrs
p Graphic3d
p Image
p ImageUtility
p MeshVS
p NIS
p OpenGl
@@ -222,13 +223,13 @@ p StdPrs
p StdSelect
p TColQuantity
p V3d
p Viewer
p Visual3d
p Voxel
p WNT
p Xw
p Cocoa
r Textures
r Shaders
t TKMeshVS
t TKNIS
t TKOpenGl

View File

@@ -1,7 +0,0 @@
@echo off
rem Setup environment and launch DRAWEXE
call "%~dp0env.bat"
echo Hint: use "pload ALL" command to load standard commands
DRAWEXE.exe

View File

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

View File

@@ -1,59 +0,0 @@
echo off
set "SCRIPTROOT=%~dp0"
set "SCRIPTROOT=%SCRIPTROOT:~0,-1%"
if ["%CASROOT%"] == [""] set "CASROOT=%SCRIPTROOT%"
set "TCL_DIR=@3RDPARTY_TCL_DLL_DIR@"
if not ["%TCL_DIR%"] == [""] set "PATH=%TCL_DIR%;%PATH%"
set "FREETYPE_DIR=@3RDPARTY_FREETYPE_DLL_DIR@"
if not ["%FREETYPE_DIR%"] == [""] set "PATH=%FREETYPE_DIR%;%PATH%"
set "FREEIMAGE_DIR=@3RDPARTY_FREEIMAGE_DLL_DIR@"
if not ["%FREEIMAGE_DIR%"] == [""] set "PATH=%FREEIMAGE_DIR%;%PATH%"
set "GL2PS_DIR=@3RDPARTY_GL2PS_DLL_DIR@"
if not ["%GL2PS_DIR%"] == [""] set "PATH=%GL2PS_DIR%;%PATH%"
set "TBB_DIR=@3RDPARTY_TBB_DLL_DIR@"
if not ["%TBB_DIR%"] == [""] set "PATH=%TBB_DIR%;%PATH%"
rem ----- Set path to 3rd party and OCCT libraries -----
set "PATH=%CASROOT%\bin;%PATH%"
rem ----- Set envoronment variables used by OCCT -----
set CSF_LANGUAGE=us
set MMGT_CLEAR=1
set CSF_EXCEPTION_PROMPT=1
set "CSF_SHMessage=%CASROOT%\src\SHMessage"
set "CSF_MDTVTexturesDirectory=%CASROOT%\src\Textures"
set "CSF_ShadersDirectory=%CASROOT%\src\Shaders"
set "CSF_XSMessage=%CASROOT%\src\XSMessage"
set "CSF_TObjMessage=%CASROOT%\src\TObj"
set "CSF_StandardDefaults=%CASROOT%\src\StdResource"
set "CSF_PluginDefaults=%CASROOT%\src\StdResource"
set "CSF_XCAFDefaults=%CASROOT%\src\StdResource"
set "CSF_TObjDefaults=%CASROOT%\src\StdResource"
set "CSF_StandardLiteDefaults=%CASROOT%\src\StdResource"
set "CSF_UnitsLexicon=%CASROOT%\src\UnitsAPI\Lexi_Expr.dat"
set "CSF_UnitsDefinition=%CASROOT%\src\UnitsAPI\Units.dat"
set "CSF_IGESDefaults=%CASROOT%\src\XSTEPResource"
set "CSF_STEPDefaults=%CASROOT%\src\XSTEPResource"
set "CSF_XmlOcafResource=%CASROOT%\src\XmlOcafResource"
set "CSF_MIGRATION_TYPES=%CASROOT%\src\StdResource\MigrationSheet.txt"
rem Draw Harness special stuff
if exist "%CASROOT%\src\DrawResources" (
set "DRAWHOME=%CASROOT%\src\DrawResources"
set "CSF_DrawPluginDefaults=%CASROOT%\src\DrawResources"
if exist "%CASROOT%\src\DrawResources\DrawDefault" (
set "DRAWDEFAULT=%CASROOT%\src\DrawResources\DrawDefault"
)
)
if exist "%CASROOT%\src\DrawResourcesProducts" (
set "CSF_DrawPluginProductsDefaults=%CASROOT%\src\DrawResourcesProducts"
)

View File

@@ -1,101 +0,0 @@
#!/bin/bash
aScriptPath=${BASH_SOURCE%/*}; if [ -d "${aScriptPath}" ]; then cd "$aScriptPath"; fi; aScriptPath="$PWD";
if [ "${CASROOT}" == "" ]; then
export CASROOT="${aScriptPath}"
fi
aLibPath="${CASROOT}/lib"
TCL_DIR="@3RDPARTY_TCL_DLL_DIR@"
if [ "$TCL_DIR" != "" ]; then
aLibPath="${TCL_DIR}:${aLibPath}"
fi
FREETYPE_DIR="@3RDPARTY_FREETYPE_DLL_DIR@"
if [ "$FREETYPE_DIR" != "" ]; then
aLibPath="${FREETYPE_DIR}:${aLibPath}"
fi
FREEIMAGE_DIR="@3RDPARTY_FREEIMAGE_DLL_DIR@"
if [ "$FREEIMAGE_DIR" != "" ]; then
aLibPath="${FREEIMAGE_DIR}:${aLibPath}"
fi
GL2PS_DIR="@3RDPARTY_GL2PS_DLL_DIR@"
if [ "$GL2PS_DIR" != "" ]; then
aLibPath="${GL2PS_DIR}:${aLibPath}"
fi
TBB_DIR="@3RDPARTY_TBB_DLL_DIR@"
if [ "$TBB_DIR" != "" ]; then
aLibPath="${TBB_DIR}:${aLibPath}"
fi
# ----- Set path to 3rd party and OCCT libraries -----
aSystem=`uname -s`
if [ "$aSystem" == "Darwin" ]; then
export WOKSTATION="mac";
if [ "$DYLD_LIBRARY_PATH" != "" ]; then
export DYLD_LIBRARY_PATH="${aLibPath}:${DYLD_LIBRARY_PATH}"
else
export DYLD_LIBRARY_PATH="${aLibPath}"
fi
else
export WOKSTATION="lin";
if [ "$LD_LIBRARY_PATH" != "" ]; then
export LD_LIBRARY_PATH="${aLibPath}:${LD_LIBRARY_PATH}"
else
export LD_LIBRARY_PATH="${aLibPath}"
fi
fi
# ----- Set path to OCCT executables -----
PATH="${PATH}:${CASROOT}/bin"
# ----- Setup Environment Variables -----
anArch=`uname -m`
if [ "$anArch" != "x86_64" ] && [ "$anArch" != "ia64" ]; then
export ARCH="32";
else
export ARCH="64";
fi
if [ "$aSystem" == "Darwin" ]; then
export ARCH="64";
fi
# ----- Set envoronment variables used by OCCT -----
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"
# Draw Harness special stuff
if [ -e "${CASROOT}/src/DrawResources" ]; then
export DRAWHOME="${CASROOT}/src/DrawResources"
export CSF_DrawPluginDefaults="${CASROOT}/src/DrawResources"
if [ -e "${CASROOT}/src/DrawResources/DrawDefault" ]; then
export DRAWDEFAULT="${CASROOT}/src/DrawResources/DrawDefault"
fi
fi
if [ -e "${CASROOT}/src/DrawResourcesProducts" ]; then
export CSF_DrawPluginProductsDefaults="${CASROOT}/src/DrawResourcesProducts"
fi

View File

@@ -1,28 +0,0 @@
@echo off
if ["%1"] == [""] (
echo Launch selected sample as follows:
echo sample.bat SampleName
echo available samples:
echo Geometry
echo Modeling
echo Viewer2d
echo Viewer3d
echo ImportExport
echo Ocaf
echo Triangulation
echo HLR
echo Animation
echo Convert
exit /B
)
if not exist "%~dp0/bin/%1.exe" (
echo Executable %~dp0/bin/%4.exe not found.
echo Probably you didn't compile the application.
exit /B
)
call "%~dp0/env.bat"
"%~dp0/bin/%1.exe"

View File

@@ -1,109 +0,0 @@
# Find tbb includes and libraries
IF(${COMPILER_BITNESS} STREQUAL 32)
SET (TBB_ARCH_NAME ia32)
ELSE()
SET (TBB_ARCH_NAME intel64)
ENDIF()
IF(NOT DEFINED 3RDPARTY_TBB_DIR)
SET(3RDPARTY_TBB_DIR "" CACHE PATH "Directory contains tbb product")
ENDIF()
SET(3RDPARTY_TBB_DIR_NAME "")
IF(3RDPARTY_DIR AND ("${3RDPARTY_TBB_DIR}" STREQUAL "" OR CHANGES_ARE_NEEDED))
FIND_PRODUCT_DIR("${3RDPARTY_DIR}" "TBB" 3RDPARTY_TBB_DIR_NAME)
IF("${3RDPARTY_TBB_DIR_NAME}" STREQUAL "")
MESSAGE(STATUS "TBB DON'T FIND")
ELSE()
SET(3RDPARTY_TBB_DIR "${3RDPARTY_DIR}/${3RDPARTY_TBB_DIR_NAME}" CACHE PATH "Directory contains tbb product" FORCE)
ENDIF()
ENDIF()
SET(INSTALL_TBB OFF CACHE BOOL "Is tbb lib copy to install directory")
IF(3RDPARTY_TBB_DIR)
IF("${3RDPARTY_TBB_INCLUDE_DIR}" STREQUAL "" OR CHANGES_ARE_NEEDED)
SET(3RDPARTY_TBB_INCLUDE_DIR "3RDPARTY_TBB_INCLUDE_DIR-NOTFOUND" CACHE PATH "Directory contains headers of the tbb product" FORCE)
FIND_PATH(3RDPARTY_TBB_INCLUDE_DIR tbb/tbb.h PATHS "${3RDPARTY_TBB_DIR}/include")
ENDIF()
SET(TBB_DEBUG_POSTFIX "")
if("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
SET(TBB_DEBUG_POSTFIX "_debug")
ENDIF()
IF("${3RDPARTY_TBB_LIBRARY}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_TBB_LIBRARY}" STREQUAL "3RDPARTY_TBB_LIBRARY-NOTFOUND")
SET(3RDPARTY_TBB_LIBRARY "3RDPARTY_TBB_LIBRARY-NOTFOUND" CACHE PATH "Directory contains library of the tbb product" FORCE)
FIND_LIBRARY(3RDPARTY_TBB_LIBRARY tbb${TBB_DEBUG_POSTFIX} PATHS "${3RDPARTY_TBB_DIR}/lib/${TBB_ARCH_NAME}/${COMPILER}" NO_DEFAULT_PATH)
IF("${3RDPARTY_TBB_LIBRARY}" STREQUAL "3RDPARTY_TBB_LIBRARY-NOTFOUND")
FIND_LIBRARY(3RDPARTY_TBB_LIBRARY tbb${TBB_DEBUG_POSTFIX})
ENDIF()
ENDIF()
IF("${3RDPARTY_TBB_MALLOC_LIBRARY}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_TBB_MALLOC_LIBRARY}" STREQUAL "3RDPARTY_TBB_MALLOC_LIBRARY-NOTFOUND")
SET(3RDPARTY_TBB_MALLOC_LIBRARY "3RDPARTY_TBB_MALLOC_LIBRARY-NOTFOUND" CACHE PATH "Directory contains library of the tbb malloc product" FORCE)
FIND_LIBRARY(3RDPARTY_TBB_MALLOC_LIBRARY tbbmalloc${TBB_DEBUG_POSTFIX} PATHS "${3RDPARTY_TBB_DIR}/lib/${TBB_ARCH_NAME}/${COMPILER}" NO_DEFAULT_PATH)
IF("${3RDPARTY_TBB_MALLOC_LIBRARY}" STREQUAL "3RDPARTY_TBB_MALLOC_LIBRARY-NOTFOUND")
FIND_LIBRARY(3RDPARTY_TBB_MALLOC_LIBRARY tbbmalloc${TBB_DEBUG_POSTFIX})
ENDIF()
ENDIF()
IF("${3RDPARTY_TBB_DLL}" STREQUAL "" OR CHANGES_ARE_NEEDED)
SET(3RDPARTY_TBB_DLL "3RDPARTY_TBB_DLL-NOTFOUND" CACHE PATH "Directory contains shared library of the tbb product" FORCE)
FIND_FILE(3RDPARTY_TBB_DLL "${DLL_SO_PREFIX}tbb${TBB_DEBUG_POSTFIX}.${DLL_SO}" PATHS "${3RDPARTY_TBB_DIR}/${DLL_SO_FOLDER}/${TBB_ARCH_NAME}/${COMPILER}" NO_DEFAULT_PATH)
IF("${3RDPARTY_TBB_DLL}" STREQUAL "3RDPARTY_TBB_DLL-NOTFOUND")
FIND_FILE(3RDPARTY_TBB_DLL "${DLL_SO_PREFIX}tbb${TBB_DEBUG_POSTFIX}.${DLL_SO}")
ENDIF()
ENDIF()
IF("${3RDPARTY_TBB_MALLOC_DLL}" STREQUAL "" OR CHANGES_ARE_NEEDED)
SET(3RDPARTY_TBB_MALLOC_DLL "3RDPARTY_TBB_MALLOC_DLL-NOTFOUND" CACHE PATH "Directory contains shared library of the tbb malloc product" FORCE)
FIND_FILE(3RDPARTY_TBB_MALLOC_DLL "${DLL_SO_PREFIX}tbbmalloc${TBB_DEBUG_POSTFIX}.${DLL_SO}" PATHS "${3RDPARTY_TBB_DIR}/${DLL_SO_FOLDER}/${TBB_ARCH_NAME}/${COMPILER}" NO_DEFAULT_PATH)
IF("${3RDPARTY_TBB_MALLOC_DLL}" STREQUAL "3RDPARTY_TBB_MALLOC_DLL-NOTFOUND")
FIND_FILE(3RDPARTY_TBB_MALLOC_DLL "${DLL_SO_PREFIX}tbbmalloc${TBB_DEBUG_POSTFIX}.${DLL_SO}")
ENDIF()
ENDIF()
MARK_AS_ADVANCED(3RDPARTY_TBB_DIR_NAME)
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TBB_DIR)
ENDIF()
IF(3RDPARTY_TBB_INCLUDE_DIR)
SET(3RDPARTY_INCLUDE_DIRS "${3RDPARTY_INCLUDE_DIRS};${3RDPARTY_TBB_INCLUDE_DIR}")
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TBB_INCLUDE_DIR)
ENDIF()
IF(3RDPARTY_TBB_LIBRARY)
GET_FILENAME_COMPONENT(3RDPARTY_TBB_LIBRARY_DIR "${3RDPARTY_TBB_LIBRARY}" PATH)
SET(3RDPARTY_LIBRARY_DIRS "${3RDPARTY_LIBRARY_DIRS};${3RDPARTY_TBB_LIBRARY_DIR}")
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TBB_LIBRARY)
ENDIF()
IF(3RDPARTY_TBB_MALLOC_LIBRARY)
GET_FILENAME_COMPONENT(3RDPARTY_TBB_LIBRARY_DIR "${3RDPARTY_TBB_MALLOC_LIBRARY}" PATH)
SET(3RDPARTY_LIBRARY_DIRS "${3RDPARTY_LIBRARY_DIRS};${3RDPARTY_TBB_LIBRARY_DIR}")
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TBB_MALLOC_LIBRARY)
ENDIF()
IF(3RDPARTY_TBB_DLL)
#
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TBB_DLL)
ENDIF()
IF(3RDPARTY_TBB_MALLOC_DLL)
#
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TBB_MALLOC_DLL)
ENDIF()

View File

@@ -1,163 +0,0 @@
# - Find Tcl includes and libraries
IF(WIN32)
SET(TCL_SEP "")
GET_FILENAME_COMPONENT(ActiveTcl_CurrentVersion
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActiveTcl;CurrentVersion]" NAME)
ELSE()
SET(TCL_SEP ".")
ENDIF()
IF(NOT DEFINED 3RDPARTY_TCL_DIR)
SET(3RDPARTY_TCL_DIR "" CACHE PATH "Directory contains TCL product")
ENDIF()
IF(3RDPARTY_DIR AND ("${3RDPARTY_TCL_DIR}" STREQUAL "" OR CHANGES_ARE_NEEDED))
FIND_PRODUCT_DIR("${3RDPARTY_DIR}" tcl TCL_DIR_NAME)
IF("${TCL_DIR_NAME}" STREQUAL "")
MESSAGE(STATUS "\nInfo: tcl folder isn't found in ${3RDPARTY_DIR}. Start seeking in default folders")
ELSE()
SET(3RDPARTY_TCL_DIR "${3RDPARTY_DIR}/${TCL_DIR_NAME}" CACHE PATH "Directory contains TCL product" FORCE)
ENDIF()
ENDIF()
SET(INSTALL_TCL OFF CACHE BOOL "Is TCL lib copy to install directory")
# include dir search
IF("${3RDPARTY_TCL_INCLUDE_DIR}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_TCL_INCLUDE_DIR}" STREQUAL "3RDPARTY_TCL_INCLUDE_DIR-NOTFOUND")
SET(3RDPARTY_TCL_INCLUDE_DIR "3RDPARTY_TCL_INCLUDE_DIR-NOTFOUND" CACHE FILEPATH "Directory contains headers of the TCL product" FORCE)
IF(NOT "${3RDPARTY_TCL_DIR}" STREQUAL "")
FIND_PATH(3RDPARTY_TCL_INCLUDE_DIR tcl.h PATHS "${3RDPARTY_TCL_DIR}/include" NO_DEFAULT_PATH)
ELSE()
SET(3RDPARTY_TCL_POSSIBLE_INCLUDE_DIRS /usr/include
/usr/local/include
/usr/include/tcl8${TCL_SEP}6
/usr/include/tcl8${TCL_SEP}5)
IF(WIN32)
SET(3RDPARTY_TCL_POSSIBLE_INCLUDE_DIRS ${3RDPARTY_TCL_POSSIBLE_INCLUDE_DIRS}
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActiveTcl\\${ActiveTcl_CurrentVersion}]/include"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Scriptics\\Tcl\\8.6;Root]/include"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Scriptics\\Tcl\\8.5;Root]/include"
"$ENV{ProgramFiles}/Tcl/include"
#"$ENV{ProgramFiles\(x86\)}/Tcl/include"
"C:/Program Files/Tcl/include"
"C:/Tcl/include")
ENDIF(WIN32)
# check default path (with additions) for header search
FIND_PATH(3RDPARTY_TCL_INCLUDE_DIR tcl.h PATHS ${3RDPARTY_TCL_POSSIBLE_INCLUDE_DIRS})
#if find_path found something - set 3RDPARTY_TCL_DIR
IF(NOT "${3RDPARTY_TCL_INCLUDE_DIR}" STREQUAL "3RDPARTY_TCL_INCLUDE_DIR-NOTFOUND")
GET_FILENAME_COMPONENT (3RDPARTY_TCL_DIR "${3RDPARTY_TCL_INCLUDE_DIR}/../" ABSOLUTE)
SET(3RDPARTY_TCL_DIR ${3RDPARTY_TCL_DIR} CACHE FILEPATH "Directory contains TCL product" FORCE)
ENDIF()
ENDIF()
ENDIF()
#library dir search
IF("${3RDPARTY_TCL_LIBRARY}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_TCL_LIBRARY}" STREQUAL "3RDPARTY_TCL_LIBRARY-NOTFOUND")
SET(3RDPARTY_TCL_LIBRARY "3RDPARTY_TCL_LIBRARY-NOTFOUND" CACHE FILEPATH "Path to library of the TCL product" FORCE)
IF(NOT "${3RDPARTY_TCL_DIR}" STREQUAL "")
FIND_LIBRARY(3RDPARTY_TCL_LIBRARY
NAMES tcl tcl8${TCL_SEP}6 tcl8${TCL_SEP}5
PATHS "${3RDPARTY_TCL_DIR}/lib" NO_DEFAULT_PATH)
ELSE()
SET(3RDPARTY_TCL_POSSIBLE_LIBRARIES_DIRS /usr/lib /usr/local/lib)
IF(WIN32)
SET(3RDPARTY_TCL_POSSIBLE_LIBRARIES_DIRS ${3RDPARTY_TCL_POSSIBLE_LIBRARIES_DIRS}
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActiveTcl\\${ActiveTcl_CurrentVersion}]/lib"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Scriptics\\Tcl\\8.6;Root]/lib"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Scriptics\\Tcl\\8.5;Root]/lib"
"$ENV{ProgramFiles}/Tcl/Lib"
"C:/Program Files/Tcl/lib"
"C:/Tcl/lib" )
ENDIF()
# check default path (with additions) for library search
FIND_LIBRARY(3RDPARTY_TCL_LIBRARY
NAMES tcl tcl8${TCL_SEP}6 tcl8${TCL_SEP}5
PATHS ${3RDPARTY_TCL_POSSIBLE_LIBRARIES_DIRS})
ENDIF()
ENDIF()
#search the version of found tcl library
IF("${3RDPARTY_TCL_LIBRARY}" STREQUAL "" OR "${3RDPARTY_TCL_LIBRARY}" STREQUAL "3RDPARTY_TCL_LIBRARY-NOTFOUND")
SET (TCL_DLL_SO_NAMES ${DLL_SO_PREFIX}tcl.${DLL_SO}
${DLL_SO_PREFIX}tcl8${TCL_SEP}5.${DLL_SO}
${DLL_SO_PREFIX}tcl8${TCL_SEP}6.${DLL_SO} )
ELSE()
GET_FILENAME_COMPONENT(TCL_LIBRARY_NAME "${3RDPARTY_TCL_LIBRARY}" NAME)
STRING(REGEX REPLACE "^.*tcl([0-9])[^0-9]*[0-9].*$" "\\1" TCL_MAJOR_VERSION "${TCL_LIBRARY_NAME}")
STRING(REGEX REPLACE "^.*tcl[0-9][^0-9]*([0-9]).*$" "\\1" TCL_MINOR_VERSION "${TCL_LIBRARY_NAME}")
IF (NOT "${TCL_MAJOR_VERSION}" STREQUAL "${TCL_LIBRARY_NAME}")
SET (IS_TCL_VERSION_FOUND ON)
ELSE()
SET (IS_TCL_VERSION_FOUND OFF)
ENDIF()
IF (IS_TCL_VERSION_FOUND)
SET (TCL_DLL_SO_NAMES "${DLL_SO_PREFIX}tcl${TCL_MAJOR_VERSION}${TCL_SEP}${TCL_MINOR_VERSION}.${DLL_SO}")
ELSE()
MESSAGE(STATUS "\nWarning: Tcl version isn't found. ${DLL_SO_PREFIX}tcl.${DLL_SO} is used")
SET (TCL_DLL_SO_NAMES "${DLL_SO_PREFIX}tcl.${DLL_SO}")
ENDIF()
ENDIF()
#dll_so search
IF("${3RDPARTY_TCL_DLL}" STREQUAL "" OR CHANGES_ARE_NEEDED OR "${3RDPARTY_TCL_DLL}" STREQUAL "3RDPARTY_TCL_DLL-NOTFOUND")
SET(3RDPARTY_TCL_DLL "3RDPARTY_TCL_DLL-NOTFOUND" CACHE FILEPATH "Path to shared library of the TCL product" FORCE)
IF(NOT "${3RDPARTY_TCL_DIR}" STREQUAL "")
FIND_FILE(3RDPARTY_TCL_DLL
NAMES ${TCL_DLL_SO_NAMES}
PATHS "${3RDPARTY_TCL_DIR}/${DLL_SO_FOLDER}" NO_DEFAULT_PATH)
ELSE()
SET(3RDPARTY_TCL_POSSIBLE_SO_DIRS /usr/lib /usr/local/lib)
IF(WIN32)
SET(3RDPARTY_TCL_POSSIBLE_SO_DIRS ${3RDPARTY_TCL_POSSIBLE_SO_DIRS}
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActiveTcl\\${ActiveTcl_CurrentVersion}]/bin"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Scriptics\\Tcl\\8.6;Root]/bin"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Scriptics\\Tcl\\8.5;Root]/bin"
"$ENV{ProgramFiles}/Tcl/Bin"
"C:/Program Files/Tcl/bin"
"C:/Tcl/b" )
ENDIF()
# check default path (with additions) for dll_so search
FIND_FILE(3RDPARTY_TCL_DLL
NAMES ${TCL_DLL_SO_NAMES}
PATHS ${3RDPARTY_TCL_POSSIBLE_SO_DIRS})
ENDIF()
ENDIF()
IF(NOT "${3RDPARTY_TCL_DIR}" STREQUAL "")
MARK_AS_ADVANCED(3RDPARTY_TCL_DIR)
ENDIF()
# #includes found paths to common variables
IF(3RDPARTY_TCL_INCLUDE_DIR)
SET(3RDPARTY_INCLUDE_DIRS "${3RDPARTY_INCLUDE_DIRS};${3RDPARTY_TCL_INCLUDE_DIR}")
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TCL_INCLUDE_DIR)
ENDIF()
IF(3RDPARTY_TCL_LIBRARY)
GET_FILENAME_COMPONENT(3RDPARTY_TCL_LIBRARY_DIR "${3RDPARTY_TCL_LIBRARY}" PATH)
SET(3RDPARTY_LIBRARY_DIRS "${3RDPARTY_LIBRARY_DIRS};${3RDPARTY_TCL_LIBRARY_DIR}")
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TCL_LIBRARY)
ENDIF()
IF(3RDPARTY_TCL_DLL)
ELSE()
LIST(APPEND 3RDPARTY_NOT_INCLUDED 3RDPARTY_TCL_DLL)
ENDIF()

Binary file not shown.

Before

Width:  |  Height:  |  Size: 298 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 397 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 356 B

View File

@@ -1,188 +0,0 @@
<doxygenlayout version="1.0">
<!-- Generated by doxygen 1.8.3.1 -->
<!-- Navigation index tabs for HTML output -->
<navindex>
<tab type="mainpage" visible="yes" title="Introduction"/>
<tab type="pages" visible="yes" title="Documents" intro="This section contains links to all OCCT documents that are available at the moment"/>
<tab type="modules" visible="yes" title="" intro=""/>
<tab type="namespaces" visible="yes" title="">
<tab type="namespacelist" visible="no" title="" intro=""/>
<tab type="namespacemembers" visible="yes" title="" intro=""/>
</tab>
<tab type="classes" visible="yes" title="Reference Manual">
<tab type="classlist" visible="no" title="" intro=""/>
<tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/>
<tab type="hierarchy" visible="no" title="" intro=""/>
<tab type="classmembers" visible="no" title="" intro=""/>
</tab>
<tab type="files" visible="no" title="Files">
<tab type="filelist" visible="yes" title="" intro=""/>
<tab type="globals" visible="yes" title="" intro=""/>
</tab>
<tab type="examples" visible="no" title="" intro=""/>
</navindex>
<!-- Layout definition for a class page -->
<class>
<briefdescription visible="yes"/>
<includes visible="$SHOW_INCLUDE_FILES"/>
<inheritancegraph visible="$CLASS_GRAPH"/>
<collaborationgraph visible="$COLLABORATION_GRAPH"/>
<memberdecl>
<nestedclasses visible="yes" title=""/>
<publictypes title=""/>
<publicslots title=""/>
<signals title=""/>
<publicmethods title=""/>
<publicstaticmethods title=""/>
<publicattributes title=""/>
<publicstaticattributes title=""/>
<protectedtypes title=""/>
<protectedslots title=""/>
<protectedmethods title=""/>
<protectedstaticmethods title=""/>
<protectedattributes title=""/>
<protectedstaticattributes title=""/>
<packagetypes title=""/>
<packagemethods title=""/>
<packagestaticmethods title=""/>
<packageattributes title=""/>
<packagestaticattributes title=""/>
<properties title=""/>
<events title=""/>
<privatetypes title=""/>
<privateslots title=""/>
<privatemethods title=""/>
<privatestaticmethods title=""/>
<privateattributes title=""/>
<privatestaticattributes title=""/>
<friends title=""/>
<related title="" subtitle=""/>
<membergroups visible="yes"/>
</memberdecl>
<detaileddescription title=""/>
<memberdef>
<inlineclasses title=""/>
<typedefs title=""/>
<enums title=""/>
<constructors title=""/>
<functions title=""/>
<related title=""/>
<variables title=""/>
<properties title=""/>
<events title=""/>
</memberdef>
<allmemberslink visible="yes"/>
<usedfiles visible="$SHOW_USED_FILES"/>
<authorsection visible="yes"/>
</class>
<!-- Layout definition for a namespace page -->
<namespace>
<briefdescription visible="yes"/>
<memberdecl>
<nestednamespaces visible="yes" title=""/>
<classes visible="yes" title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
<membergroups visible="yes"/>
</memberdecl>
<detaileddescription title=""/>
<memberdef>
<inlineclasses title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
</memberdef>
<authorsection visible="yes"/>
</namespace>
<!-- Layout definition for a file page -->
<file>
<briefdescription visible="yes"/>
<includes visible="$SHOW_INCLUDE_FILES"/>
<includegraph visible="$INCLUDE_GRAPH"/>
<includedbygraph visible="$INCLUDED_BY_GRAPH"/>
<sourcelink visible="yes"/>
<memberdecl>
<classes visible="yes" title=""/>
<namespaces visible="yes" title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
<membergroups visible="yes"/>
</memberdecl>
<detaileddescription title=""/>
<memberdef>
<inlineclasses title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
</memberdef>
<authorsection/>
</file>
<!-- Layout definition for a group page -->
<group>
<briefdescription visible="yes"/>
<groupgraph visible="$GROUP_GRAPHS"/>
<memberdecl>
<nestedgroups visible="yes" title=""/>
<dirs visible="yes" title=""/>
<files visible="yes" title=""/>
<namespaces visible="yes" title=""/>
<classes visible="yes" title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<enumvalues title=""/>
<functions title=""/>
<variables title=""/>
<signals title=""/>
<publicslots title=""/>
<protectedslots title=""/>
<privateslots title=""/>
<events title=""/>
<properties title=""/>
<friends title=""/>
<membergroups visible="yes"/>
</memberdecl>
<detaileddescription title=""/>
<memberdef>
<pagedocs/>
<inlineclasses title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<enumvalues title=""/>
<functions title=""/>
<variables title=""/>
<signals title=""/>
<publicslots title=""/>
<protectedslots title=""/>
<privateslots title=""/>
<events title=""/>
<properties title=""/>
<friends title=""/>
</memberdef>
<authorsection visible="yes"/>
</group>
<!-- Layout definition for a directory page -->
<directory>
<briefdescription visible="yes"/>
<directorygraph visible="yes"/>
<memberdecl>
<dirs visible="yes"/>
<files visible="yes"/>
</memberdecl>
<detaileddescription title=""/>
</directory>
</doxygenlayout>

View File

@@ -1,55 +0,0 @@
# This file contains list of documentation files of OCCT which are processed
# by Doxygen to generate HTML documentation.
# Files are listed one file per line, with paths relative to dox folder.
# Empty spaces are allowed, part of string starting with # is ignored.
# The order of files in this list determines order of top-level pages
# in the generated documentation.
overview/overview.md
../samples/mfc/standard/ReadMe.md
../samples/CSharp/ReadMe.md
tutorial/tutorial.md
technical_overview/technical_overview.md
user_guides/user_guides.md
user_guides/foundation_classes/foundation_classes.md
user_guides/modeling_data/modeling_data.md
user_guides/modeling_algos/modeling_algos.md
user_guides/visualization/visualization.md
user_guides/iges/iges.md
user_guides/step/step.md
user_guides/xde/xde.md
user_guides/ocaf/ocaf.md
user_guides/tobj/tobj.md
user_guides/shape_healing/shape_healing.md
user_guides/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/voxels_wp/voxels_wp.md
dev_guides/dev_guides.md
dev_guides/documentation/documentation.md
dev_guides/contribution/coding_rules.md
dev_guides/contribution_workflow/contribution_workflow.md
dev_guides/git_guide/git_guide.md
dev_guides/tests/tests.md
dev_guides/cdl/cdl.md
dev_guides/wok/wok.md
dev_guides/building/building.md
dev_guides/building/3rdparty/3rdparty_windows.md
dev_guides/building/3rdparty/3rdparty_linux.md
dev_guides/building/3rdparty/3rdparty_osx.md
dev_guides/building/wok/wok.md
dev_guides/building/automake.md
dev_guides/building/cmake/cmake.md
dev_guides/building/code_blocks.md
dev_guides/building/msvc.md
dev_guides/building/xcode.md
license.md

View File

@@ -1,264 +0,0 @@
 Building 3rd-party libraries on Linux {#dev_guides__building_3rdparty_linux}
=========
@tableofcontents
@section dev_guides__building_3rdparty_linux_1 Introduction
This document presents additional guidelines for building third-party
products used by Open CASCADE Technology and samples on Linux platform.
The links for downloading the third-party products are available on the web site
of OPEN CASCADE SAS at
http://www.opencascade.org/getocc/require/.
There are two types of third-party products, which are necessary to build OCCT:
* Mandatory products: Tcl/Tk 8.5 - 8.6 and  FreeType 2.4.10 - 2.4.11
* Optional products: TBB 3.x - 4.x, gl2ps 1.3.5 - 1.3.8, FreeImage 3.14.1 - 3.15.4
@section dev_guides__building_3rdparty_linux_2 Building Mandatory Third-party Products
@subsection dev_guides__building_3rdparty_linux_2_1 Tcl/Tk
Tcl/Tk is required for DRAW test harness.
@subsubsection dev_guides__building_3rdparty_linux_2_1_1 Installation from binaries:
It is possible to download ready-to-install binaries from
http://www.activestate.com/activetcl/downloads
1. Download the binaries archive and unpack them to some TCL_SRC_DIR.
2. Enter the directory TCL_SRC_DIR.
cd TCL_SRC_DIR
3. Run the install command
install.sh
and follow instructions.
@subsubsection dev_guides__building_3rdparty_linux_2_1_2 Installation from sources: Tcl
Download the necessary archive from http://www.tcl.tk/software/tcltk/download.html and unpack it.
1. Enter the unix sub-directory of the directory where the source files of Tcl are located (TCL_SRC_DIR).
cd TCL_SRC_DIR/unix
2. Run the configure command
configure --enable-gcc --enable-shared --enable-threads --prefix=TCL_INSTALL_DIR
For a 64 bit platform also add --enable-64bit option to the command line.
3. If the configure command has finished successfully, start the building process
make
4. If building is finished successfully, start the installation of Tcl.
All binary and service files of the product will be copied to the directory defined by TCL_INSTALL_DIR
make install
@subsubsection dev_guides__building_3rdparty_linux_2_1_3 Installation from sources: Tk
Download the necessary archive from http://www.tcl.tk/software/tcltk/download.html and unpack it.
1. Enter the unix sub-directory of the directory where the source files of Tk are located (TK_SRC_DIR).
cd TK_SRC_DIR/unix
2. Run the configure command, where TCL_LIB_DIR is TCL_INSTALL_DIR/lib
configure --enable-gcc --enable-shared --enable-threads --with-tcl=TCL_LIB_DIR --prefix=TK_INSTALL_DIR
where TCL_LIB_DIR is TCL_INSTALL_DIR/lib
For a 64 bit platform also add --enable-64bit option to the command line.
3. If the configure command has finished successfully, start the building process
make
4. If building has finished successfully, start the installation of Tk.
All binary and service files of the product will be copied
to the directory defined by TK_INSTALL_DIR (usually TK_INSTALL_DIR is TCL_INSTALL_DIR)
make install
@subsection dev_guides__building_3rdparty_linux_2_2 FreeType
FreeType is required for display of text in 3D viewer.
Download the necessary archive from http://sourceforge.net/projects/freetype/files/ and unpack it.
1. Enter the directory where the source files of FreeType are located (FREETYPE_SRC_DIR).
cd FREETYPE_SRC_DIR
2. Run the configure command
configure --prefix=FREETYPE_INSTALL_DIR
For a 64 bit platform also add CFLAGS='-m64 -fPIC' CPPFLAGS='-m64 -fPIC' option to the command line.
3. If the configure command has finished successfully, start the building process
make
4. If building has finished successfully, start the installation of FreeType.
All binary and service files of the product will be copied to the directory defined by FREETYPE_INSTALL_DIR
make install
@section dev_guides__building_3rdparty_linux_3 Building Optional Third-party Products
@subsection dev_guides__building_3rdparty_linux_3_1 TBB
This third-party product is installed with binaries from the archive that can be downloaded from http://threadingbuildingblocks.org.
Go to \"Downloads page\", find the release version you need and pick the archive for Linux platform.
To install, unpack the downloaded archive of TBB product.
@subsection dev_guides__building_3rdparty_linux_3_2 gl2ps
Download the necessary archive from http://geuz.org/gl2ps/ and unpack it.
1. Install or build cmake product from source file.
2. Start cmake in GUI mode with the directory where the source files of gl2ps are located:
ccmake GL2PS_SRC_DIR
a. Press [c] to make the initial configuration
b. Define the necessary options CMAKE_INSTALL_PREFIX
c. Press [c] to make the final configuration
d. Press [g] to generate Makefile and exit
or just run the following command:
cmake DCMAKE_INSTALL_PREFIX=GL2PS_INSTALL_DIR DCMAKE_BUILD_TYPE=Release
3. Start building of gl2ps
make
4. Start the installation of gl2ps. Binaries will be installed according to the CMAKE_INSTALL_PREFIX option
make install
@subsection dev_guides__building_3rdparty_linux_3_3 FreeImage
Download the necessary archive from http://sourceforge.net/projects/freeimage/files/Source%20Distribution/
and unpack it. The directory with unpacked sources is further referred to as FREEIMAGE_SRC_DIR.
1. Modify FREEIMAGE_SRC_DIR/Source/OpenEXR/Imath/ImathMatrix.h:
In line 60 insert the following:
#include string.h
2. Enter the directory where the source files of FreeImage are located (FREEIMAGE_SRC_DIR).
cd FREEIMAGE_SRC_DIR
3. Run the building process
make
4. Run the installation process
a. If you have permissions to write to /usr/include and /usr/lib directories then run the following command:
make install
b. If you dont have permissions to write to /usr/include and
/usr/lib directories then you need to modify the file FREEIMAGE_SRC_DIR/Makefile.gnu:
Change lines 7-9 from:
DESTDIR ?= /
INCDIR ?= $(DESTDIR)/usr/include
INSTALLDIR ?= $(DESTDIR)/usr/lib
to:
DESTDIR ?= $(DESTDIR)
INCDIR ?= $(DESTDIR)/include
INSTALLDIR ?= $(DESTDIR)/lib
Change lines 65-67 from:
install -m 644 -o root -g root $(HEADER) $(INCDIR)
install -m 644 -o root -g root $(STATICLIB) $(INSTALLDIR)
install -m 755 -o root -g root $(SHAREDLIB) $(INSTALLDIR)
to:
install -m 755 $(HEADER) $(INCDIR)
install -m 755 $(STATICLIB) $(INSTALLDIR)
install -m 755 $(SHAREDLIB) $(INSTALLDIR)
Change line 70 from: 
ldconfig
to:
\#ldconfig
Then run the installation process by the following command:
make DESTDIR=FREEIMAGE_INSTALL_DIR install
5. Clean the temporary files
make clean
@subsection dev_guides__building_3rdparty_linux_3_4 OpenCL ICD Loader
If you have OpenCL SDK (one provided by Apple, AMD, NVIDIA, Intel, or other
vendor) installed on your system, you should find OpenCL headers and
libraries required for building OCCT inside that SDK.
Alternatively, you can use OpenCL ICD (Installable Client Driver) Loader
provided by Khronos group. The following describes steps used to build OpenCL
ICD Loader version 1.2.11.0.
1. Download OpenCL ICD Loader sources archive and OpenCL header files from
Khronos OpenCL Registry
http://www.khronos.org/registry/cl/
2. Unpack the archive and put headers in **inc/CL** sub-folder
3. Print **make** in root of unpacked archive to compile OpenCL libraries.
4. Create installation folder for OpenCL IDL Loader package and put there:
1. OpenCL header files in **include/CL** subfolder
2. **libOpenCL.so** (generated in **bin** subfolder of source package) in **lib** subfolder
@section dev_guides__building_3rdparty_linux_4 Installation From Official Repositories
@subsection dev_guides__building_3rdparty_linux_4_1 Debian-based distributives
All 3rd-party products required for building of OCCT could be installed
from official repositories. You may install them from console using apt-get utility:
sudo apt-get install \
tcllib tklib tcl-dev tk-dev \
libfreetype-dev \
libxt-dev libxmu-dev \
libgl1-mesa-dev \
libfreeimage-dev \
libtbb-dev \
libgl2ps-dev
To launch WOK-prebuilt binaries you need install C shell and 32-bit libraries on x86_64 distributives:
sudo apt-get install \
csh \
libstdc++5:i386 libxt6:i386
Any compliant C++ compiler is required for building anyway:
sudo apt-get install \
g++

View File

@@ -1,218 +0,0 @@
 Building 3rd-party libraries on MacOS X {#dev_guides__building_3rdparty_osx}
==============================================
@tableofcontents
@section dev_guides__building_3rdparty_osx_1 Introduction
This document presents additional guidelines for building third-party products
used by Open CASCADE Technology and samples on Mac OS X platform (10.6.4 and later).
The links for downloading the third-party products are available
on the web site of OPEN CASCADE SAS at
http://www.opencascade.org/getocc/require/</a>.
There are two types of third-party products, which are necessary to build OCCT:
* Mandatory products: Tcl 8.5, Tk 8.5, FreeType 2.4.10
* Optional products: TBB 3.x or 4.x, gl2ps 1.3.5, FreeImage 3.14.1 or 3.15.x
@section dev_guides__building_3rdparty_osx_2 Building Mandatory Third-party Products
@subsection dev_guides__building_3rdparty_osx_2_1 Tcl/Tk 8.5
Tcl/Tk is required for DRAW test harness. Version 8.5 or 8.6 can be used with OCCT.
@subsubsection dev_guides__building_3rdparty_osx_2_1_1 Installation from binaries
It is possible to download ready-to-install binaries from
http://www.activestate.com/activetcl/downloads
1. Download the disk image to some TCL_DOWNLOAD_DIR.
2. Open in Finder the directory TCL_DOWNLOAD_DIR.
3. Open disk image and follow instructions.
@subsubsection dev_guides__building_3rdparty_osx_2_1_2 Installation from sources: Tcl 8.5
Download the necessary archive from http://www.tcl.tk/software/tcltk/download.html and unpack it.
1. Enter the macosx sub-directory of the directory where the source files of Tcl are located (TCL_SRC_DIR).
cd TCL_SRC_DIR/macosx
2. Run the configure command
configure --enable-gcc --enable-shared --enable-threads --prefix=TCL_INSTALL_DIR
For a 64 bit platform also add --enable-64bit option to the command line.
3. If the configure command has finished successfully, start the building process
make
4. If building is finished successfully, start the installation of Tcl.
All binary and service files of the product will be copied to the directory defined by TCL_INSTALL_DIR
make install
@subsubsection dev_guides__building_3rdparty_osx_2_1_3 Installation from sources: Tk 8.5
Download the necessary archive from http://www.tcl.tk/software/tcltk/download.html and unpack it.
1. Enter the macosx sub-directory of the directory where the source files of Tk are located (TK_SRC_DIR).
cd TK_SRC_DIR/macosx
2. Run the configure command, where TCL_LIB_DIR is TCL_INSTALL_DIR/lib
configure --enable-gcc --enable-shared --enable-threads --with-tcl=TCL_LIB_DIR --prefix=TK_INSTALL_DIR
where TCL_LIB_DIR is TCL_INSTALL_DIR/lib. For a 64 bit platform also add --enable-64bit option to the command line.
3. If the configure command has finished successfully, start the building process
make
4. If building has finished successfully, start the installation of Tk.
All binary and service files of the product will be copied to the directory
defined by TK_INSTALL_DIR (usually TK_INSTALL_DIR is TCL_INSTALL_DIR)
make install
@subsection dev_guides__building_3rdparty_osx_2_2 FreeType 2.4.10
FreeType is required for display of text in 3D viewer.
Download the necessary archive from http://sourceforge.net/projects/freetype/files/ and unpack it.
1. Enter the directory where the source files of FreeType are located (FREETYPE_SRC_DIR).
cd FREETYPE_SRC_DIR
2. Run the configure command
configure --prefix=FREETYPE_INSTALL_DIR
For a 64 bit platform also add CFLAGS='-m64 -fPIC' CPPFLAGS='-m64 -fPIC' option to the command line.
3. If the configure command has finished successfully, start the building process
make
4. If building has finished successfully, start the installation of FreeType.
All binary and service files of the product will be copied to the directory defined by FREETYPE_INSTALL_DIR
make install
@section dev_guides__building_3rdparty_osx_3 Building Optional Third-party Products
@subsection dev_guides__building_3rdparty_osx_3_1 TBB 3.x or 4.x
This third-party product is installed with binaries from the archive
that can be downloaded from http://threadingbuildingblocks.org/.
Go to \"Downloads / Commercial Aligned Release\", find the release version you need (e.g. tbb30_018oss)
and pick the archive for Mac OS X platform.
To install, unpack the downloaded archive of TBB 3.0 product (*tbb30_018oss_osx.tgz*).
@subsection dev_guides__building_3rdparty_osx_3_2 gl2ps 1.3.5
Download the necessary archive from http://geuz.org/gl2ps/ and unpack it.
1. Install or build cmake product from source file.
2. Start cmake in GUI mode with the directory where the source files of fl2ps are located
ccmake GL2PS_SRC_DIR
1. Press [c] to make the initial configuration
2. Define the necessary options CMAKE_INSTALL_PREFIX
3. Press [c] to make the final configuration
4. Press [g] to generate Makefile and exit
or just run the following command:
cmake DCMAKE_INSTALL_PREFIX=GL2PS_INSTALL_DIR DCMAKE_BUILD_TYPE=Release
3. Start building of gl2ps
make
4. Start the installation of gl2ps. Binaries will be installed according to the CMAKE_INSTALL_PREFIX option
make install
@subsection dev_guides__building_3rdparty_osx_3_3 FreeImage 3.14.1 or 3.15.x
Download the necessary archive from
http://sourceforge.net/projects/freeimage/files/Source%20Distribution/
and unpack it. The directory with unpacked sources is further referred to as FREEIMAGE_SRC_DIR.
Note that for building FreeImage on Mac OS X 10.7 you should replace Makefile.osx
in FREEIMAGE_SRC_DIR by corrected one which you can find in attachment to issue #22811 in OCCT Mantis bug tracker
(http://tracker.dev.opencascade.org/file_download.php?file_id=6937&type=bug) or elsewhere.
1. If you are building FreeImage 3.15.x you can skip this step.
Modify FREEIMAGE_SRC_DIR/Source/OpenEXR/Imath/ImathMatrix.h:
In line 60 insert the following:
#include string.h
Modify FREEIMAGE_SRC_DIR/Source/FreeImage/PluginTARGA.cpp:
In line 320 replace:
SwapShort(value);
with:
SwapShort(&value);
2. Enter the directory where the source files of FreeImage are located (FREEIMAGE_SRC_DIR).
cd FREEIMAGE_SRC_DIR
3. Run the building process
make
4. Run the installation process
1. If you have permissions to write to /usr/local/include and /usr/local/lib directories then run the following command:
make install
2. If you do not have permissions to write to /usr/include and /usr/lib directories
then you need to modify the file FREEIMAGE_SRC_DIR/Makefile.osx:
Change line 49 from:   
PREFIX ?= /usr/local
to:
PREFIX ?= $(PREFIX)
  Change lines 65-69 from:
install -d -m 755 -o root -g wheel $(INCDIR) $(INSTALLDIR)
install -m 644 -o root -g wheel $(HEADER) $(INCDIR)
install -m 644 -o root -g wheel $(SHAREDLIB) $(STATICLIB) $(INSTALLDIR)
ranlib -sf $(INSTALLDIR)/$(STATICLIB)
ln -sf $(SHAREDLIB) $(INSTALLDIR)/$(LIBNAME)
to:
install -d $(INCDIR) $(INSTALLDIR)
install -m 755 $(HEADER) $(INCDIR)
install -m 755 $(STATICLIB) $(INSTALLDIR)
install -m 755 $(SHAREDLIB) $(INSTALLDIR)
ln -sf $(SHAREDLIB) $(INSTALLDIR)/$(VERLIBNAME)
ln -sf $(VERLIBNAME) $(INSTALLDIR)/$(LIBNAME)
Then run the installation process by the following command:
make PREFIX=FREEIMAGE_INSTALL_DIR install
5. Clean the temporary files
make clean

View File

@@ -1,311 +0,0 @@
 Building 3rd-party libraries on Windows {#dev_guides__building_3rdparty_windows}
==============================================
@tableofcontents
@section dev_guides__building_3rdparty_win_1 Introduction
This document presents guidelines for building third-party products
used by Open CASCADE Technology (OCCT) and samples on Windows platform.
This guide assumfamiliar with MS Visual Studio / Visual C++.
You need to use the same version of MS Visual Studio for building
all third-party products and OCCT itself, in order to receive a consistent set of run-time binaries.
The links for downloading the third-party products are available on the web site
of OPEN CASCADE SAS at http://www.opencascade.org/getocc/require/.
There are two types of third-party products which are used by OCCT:
* Mandatory products: Tcl/Tk 8.5 - 8.6 and  FreeType 2.4.10 - 2.4.11
* Optional products: TBB 3.x - 4.x, gl2ps 1.3.5 - 1.3.8, FreeImage 3.14.1 -3.15.4
It is recommended to create a separate new folder on your workstation where
you will unpack the downloaded archives of the third-party products,
and where you will build these products (for example, *c:\\occ3rdparty*).
Further in this document, this folder is referred to as *3rdparty*.
@section dev_guides__building_3rdparty_win_2 Building Mandatory Third-party Products
@subsection dev_guides__building_3rdparty_win_2_1 Tcl/Tk
Tcl/Tk is required for DRAW test harness.We recommend installing a binary distribution that could
be downloaded from http://www.activestate.com/activetcl.
Go to \"Free Downloads\" and pick the version of the Install Wizard
that matches your target platform 32 bit (x86) or 64 bit (x64).
The version of Visual Studio you use is irrelevant when choosing the Install Wizard.
Run the Install Wizard you downloaded, and install Tcl/Tk products
* to 3rdparty\\tcltk-win32 folder (for 32-bit platform) or
* to 3rdparty\\tcltk-win64 folder (for 64-bit platform).
Further in this document, this folder is referred to as *tcltk*.
@subsection dev_guides__building_3rdparty_win_2_2 FreeType
FreeType is required for display of text in 3D viewer.
You can download its sources from http://sourceforge.net/projects/freetype/files/
The building process is the following:
1. Unpack the downloaded archive of FreeType product into the *3rdparty* folder.
As a result, you should have a folder named for example, *3rdparty\\freetype-2.4.10*. Further in this document, this folder is referred to as *freetype*.
2. Open the solution file *freetype\\builds\\win32\\vc20xx\\freetype.sln* in Visual Studio, where vc20xx stands for the version of Visual Studio you are using.
3. Select a configuration to build: either Debug or Release.
4. Build the *freetype* project.
As a result, you will get a freetype import library (.lib) in the *freetype\\obj\\win32\\vc20xx* folder.
5. If you are building for 64 bit platform, start the Configuration Manager (Build - Configuration Manager),
and add *x64* platform to the solution configuration by copying the settings from Win32 platform:
@image html /dev_guides/building/3rdparty/images/3rdparty_image001.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image001.png
Update the value of the Output File for x64 configuration:
@image html /dev_guides/building/3rdparty/images/3rdparty_image003.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image003.png
Build the *freetype* project.
As a result, you should obtain a 64 bit import library (.lib) file in the *freetype\\x64\\vc20xx* folder.
If you want to build freetype as a dynamic library (.dll) follow items 6, 7 and 8 of this list.
6. Open Project-Properties-Configuration Properties-General and change option 'Configuration Type' to \"*Dynamic Library (.dll)*\".
7. Edit file *freetype\\include\\freetype\\config\\ftoption.h*:
in line 255, uncomment the definition of macro FT_EXPORT and change it as follows:
#define FT_EXPORT(x) __declspec(dllexport) x
8. Build the *freetype* project.
As a result, you should obtain import library (.lib) and dynamic library (.dll)
files in *freetype \\objs\\release or \\objs\\debug folders.*
If you are building for a 64 bit platform, follow item 5 of this list.
In order to facilitate use of the FreeType libraries in OCCT with minimal adjustment of its build procedures,
it is recommended to copy the include files and libraries of FreeType to a separate folder, named according to the pattern:
*freetype-compiler-bitness-building mode*
where
* compiler is vc8 or vc9 or vc10 or vc11;
* bitness is 32 or 64;
* building mode is opt (for Release) or deb (for Debug)
The include subfolder should be copied as is, while libraries should be renamed to
*freetype.lib* and *freetype.dll* (suffixes removed) and placed to subdirectories
*lib *and *bin*, respectively. If Debug configuration is built,
the Debug libraries should be put in subdirectories *libd* and *bind*.
@section dev_guides__building_3rdparty_win_3 Building Optional Third-party Products
@subsection dev_guides__building_3rdparty_win_3_1 TBB
This third-party product is installed with binaries
from the archive that can be downloaded from http://threadingbuildingblocks.org/.
Go to \"Downloads page\", find the release version you need (e.g. tbb30_018oss) and pick the archive for Windows platform.
Unpack the downloaded archive of TBB product into the *3rdparty* folder.
Further in this document, this folder is referred to as *tbb*.
@subsection dev_guides__building_3rdparty_win_3_2 gl2ps
This third-party product should be built as a dynamically loadable library (dll file).
You can download its sources from http://geuz.org/gl2ps/src/
The building process is the following:
1. Unpack the downloaded archive of gl2ps product (e.g. *gl2ps-1.3.5.tgz*) into the *3rdparty* folder.
As a result, you should have a folder named for example, *3rdparty\\gl2ps-1.3.5-source*.
Rename it according to the rule: gl2ps-platform-compiler-building mode, where
* platform is win32 or win64;
* compiler is vc8 or vc9 or vc10;
* building mode - opt (for release) or deb (for debug)
Further in this document, this folder is referred to as *gl2ps*.
2. Download (from http://www.cmake.org/cmake/resources/software.html)
and install the *CMake* build system.
3. Edit the file *gl2ps\\CMakeLists.txt*.
After line 113 in CMakeLists.txt:
set_target_properties(shared PROPERTIES COMPILE_FLAGS \"-DGL2PSDLL -DGL2PSDLL_EXPORTS\")
add the following line:
add_definitions(-D_USE_MATH_DEFINES)
Attention: If cygwin was installed on your computer make sure that there is no path
to the latter in the PATH variable in order to avoid possible conflicts during the configuration.
4. Launch CMake (cmake-gui.exe) using the Program menu.
In CMake:
* Define where the source code is.
This path must point to *gl2ps* folder.
* Define where to build the binaries.
This path must point to the folder where generated gl2ps project binaries will be placed
(for example, *gl2ps\\bin*).
Further in this document, this folder is referred to as *gl2ps_bin*.
* Press the \"Configure\" button.
@image html /dev_guides/building/3rdparty/images/3rdparty_image004.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image004.png
* Select the generator (the compiler and the target platform - 32 or 64 bit) in the pop-up window.
@image html /dev_guides/building/3rdparty/images/3rdparty_image005.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image005.png
* Then press the \"Finish\" button to return to the main CMake window.
Expand the ENABLE group and uncheck ENABLE_PNG and ENABLE_ZLIB check boxes.
@image html /dev_guides/building/3rdparty/images/3rdparty_image006.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image006.png
* Expand the CMAKE group and define CMAKE_INSTALL_PREFIX
(path where you want to install the build results, for example, *c:\\occ3rdparty\\gl2ps-1.3.5*).
@image html /dev_guides/building/3rdparty/images/3rdparty_image007.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image007.png
* Press the \"Configure\" button again, and then the \"Generate\" button in order to generate
Visual Studio projects. After completion, close CMake application.
5. Open the solution file *gl2ps_bin\\gl2ps.sln* in Visual Studio.
* Select a configuration to build
* Choose \"*Release*\" if you are building Release binaries.
* Choose \"*Debug*\" if you are building Debug binaries.
* Select a platform to build.
* Choose \"*Win32*\" if you are building for a 32 bit platform.
* Choose \"*x64*\" if you are building for a 64 bit platform.
* Build the solution.
* Build the *INSTALL* project.
As a result, you should have the installed gl2ps product in the *CMAKE_INSTALL_PREFIX* path.
@subsection dev_guides__building_3rdparty_win_3_3 FreeImage
This third-party product should be built as a dynamically loadable library (.dll file).
You can download its sources from
http://sourceforge.net/projects/freeimage/files/Source%20Distribution/
The building process is the following:
1. Unpack the downloaded archive of FreeImage product into *3rdparty* folder.
As a result, you should have a folder named *3rdparty\\FreeImage*.
Rename it according to the rule: freeimage-platform-compiler-building mode, where
* platform is win32 or win64;
* compiler is vc8 or vc9 or vc10 or vc11;
* building mode is opt (for release) or deb (for debug)
Further in this document, this folder is referred to as *freeimage*.
2. Open the solution file *freeimage\\FreeImage.*.sln* in Visual Studio that corresponds to the version of Visual Studio you use.
Since the version of Visual Studio you use is higher than VC++ 2008, apply conversion of the workspace.
Such conversion should be suggested automatically by Visual Studio.
3. Select a configuration to build.
- Choose \" *Release* \" if you are building Release binaries.
- Choose \" *Debug* \" if you are building Debug binaries.
*Note:*
If you want to build a debug version of FreeImage binaries then you must rename
the following files for projects FreeImage and FreeimagePlus:
Project-Properties-Configuration Properties-Linker-General-Output File
from FreeImage*d*.dll to FreeImage.dll
from FreeImagePlus*d*.dll to FreeImagePlus.dll
Project-Properties-Configuration Properties-Linker-Debugging-Generate Program Database File
from FreeImage*d*.pdb to FreeImage.pdb
from FreeImagePlus*d*.pdb to FreeImagePlus.pdb
Project-Properties-Configuration Properties-Linker-Advanced-Import Library
from FreeImage*d*.lib to FreeImage.lib
from FreeImagePlus*d*.lib to FreeImagePlus.lib
Project-Properties-Configuration Properties-Build Events-Post-Build Event-Comand Line
from FreeImage*d*.dll to FreeImage.dll
from FreeImage*d*.lib to FreeImage.lib
from FreeImagePlus*d*.dll to FreeImagePlus.dll
from FreeImagePlus*d*.lib to FreeImagePlus.lib
Additionally, for project FreeImagePlus rename:
Project-Properties-Configuration Properties-Linker-Input-Additional Dependencies
from FreeImage*d*.lib to FreeImage.lib
4. Select a platform to build.
- Choose \" *Win32* \" if you are building for a 32 bit platform.
- Choose \" *x64* \" if you are building for a 64 bit platform.
5. Start the building process.
As a result, you should have the library files of FreeImage product in the
*freeimage\\Dist* folder (FreeImage.dll and FreeImage.lib files) and in the
*freeimage\\Wrapper\\FreeImagePlus\\dist* folder (FreeImagePlus.dll and
FreeImagePlus.lib files).
@subsection dev_guides__building_3rdparty_win_opencl OpenCL ICD Loader
If you have OpenCL SDK (one provided by Apple, AMD, NVIDIA, Intel, or other
vendor) installed on your system, you should find OpenCL headers and
libraries required for building OCCT inside that SDK.
Alternatively, you can use OpenCL ICD (Installable Client Driver) Loader
provided by Khronos group. The following describes steps used to build OpenCL
ICD Loader version 1.2.11.0.
1. Download OpenCL ICD Loader sources archive and OpenCL header files from
Khronos OpenCL Registry
http://www.khronos.org/registry/cl/
2. Unpack the archive and put headers in **inc/CL** sub-folder
3. Use CMake to generate VS projects for building the library:
- Start CMake-GUI and select OpenCL ICD Loader folder as source path,
and the folder of your choice for VS project and intermediate build data
- Click Generate
- Select VS version to be used (among the one you have installed; we
recommend using VS 2010), and architecture (32- or 64-bit)
4. Open solution **OPENCL_ICD_LOADER.sln** generated in the build folder.
Though not strictly necessary, we recommend making two changes in generated
projects:
- Add file **OpenCL.rc** to project OpenCL, to have version and Khronos
copyright correctly embedded in DLL
- In properties of OpenCL project, on "C/C++ / Code Generation" page,
for Release configuration, change "Runtime library" to "Multi-threaded
(/MT)", to avoid dependency on run-time DLL.
5. Build project OpenCL in Release mode
6. Create installation folder for OpenCL IDL Loader package and put there:
- OpenCL header files in **include/CL** subfolder
- OpenCL.dll (generated in **bin/Release** subfolder of source package)
in **bin** subfolder
- OpenCL.lib (generated in **Release** subfolder of build directory)
in **lib** subfolder

Binary file not shown.

Before

Width:  |  Height:  |  Size: 123 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 84 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 106 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 65 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 206 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 236 KiB

View File

@@ -1,71 +0,0 @@
Building with Automake {#dev_guides__building__automake}
======================
This file describes steps to build OCCT libraries from complete source
archive on Linux with GNU build system (Autotools).
If you are building OCCT from bare sources (as in Git repository), or do some
changes affecting CDL files, you need to use WOK to re-generate header files
and build scripts / projects. See paragraph 1 \ref dev_guides__building__wok for instructions.
Before building OCCT, you need to install required third-party libraries; see paragraph 1 of
\ref dev_guides__building for instructions.
Note that during compilation by makefiles on some Linux OS on a station with
NVIDIA video card you may experience problems because the installation
procedure of NVIDIA video driver removes library libGL.so included in package
libMesaGL from directory /usr/X11R6/lib and places this library libGL.so in
directory /usr/lib. However, libtool expects to find the library in directory
/usr/X11R6/lib, which causes compilation crash (See /usr/X11R6/lib/libGLU.la).
To prevent this, suggest making links:
ln -s /usr/lib/libGL.so /usr/X11R6/lib/libGL.so
ln -s /usr/lib/libGL.la /usr/X11R6/lib/libGL.la
1.In OCCT root folder, launch build_configure script
This will generate files configure and Makefile.in for your system.
2.Go to the directory where OCCT will be built, and run configure to generate
makefiles.
$CASROOT/configure \<FLAGS\>
Where \<FLAGS\> is a set of options.
The following flags are mandatory:
* --with-tcl= defines location of tclConfig.sh
* --with-tk= defines location of tkConfig.sh
* --with-freetype= defines location of installed FreeType product
* --prefix= defines location for the installation of OCCT binaries
Additional flags:
* --with-gl2ps= defines location of installed gl2ps product
* --with-freeimage= defines location of installed FreeImage product
* --with-tbb-include= defines location of tbb.h
* --with-tbb-library= defines location of libtbb.so
* --with-opencl-include= defines location of cl.h
* --with-opencl-library= defines location of libOpenCL.so
* --enable-debug= yes: includes debug information, no: does not include debug information
* --enable-production= yes: switches code optimization, no: switches off code optimization
* --disable-draw - allows OCCT building without Draw.
If location of FreeImage, TBB, gl2ps or OpenCL is not specified, OCCT will be
built without these optional libraries.
Attention: 64-bit platforms are detected automatically.
Example:
> ./configure -prefix=/PRODUCTS/occt-6.5.5 --with-tcl=/PRODUCTS/tcltk-8.5.8/lib --with-tk=/PRODUCTS/tcltk-8.5.8/lib --with-freetype=/PRODUCTS/freetype-2.4.10 --with-gl2ps=/PRODUCTS/gl2ps-1.3.5 --with-freeimage=/PRODUCTS/freeimage-3.14.1 --with-tbb-include=/PRODUCTS/tbb30_018oss/include --with-tbb-library=/PRODUCTS/tbb30_018oss/lib/ia32/cc4.1.0_libc2.4_kernel2.6.16.21 --with-opencl-include=/PRODUCTS/opencl-icd-1.2.11.0/include --with-opencl-library=/PRODUCTS/opencl-icd-1.2.11.0/lib
3.If configure exits successfully, you can build OCCT with make command.
> make -j8 install
To start DRAW, launch
> draw.sh

View File

@@ -1,32 +0,0 @@
Building OCCT from sources {#dev_guides__building}
=========
In order to build OCCT libraries from these sources for use in your program,
you need to:
1. Make sure you have all required third-party libraries installed (check
software requirements in \ref OCCT_OVW_SECTION_5 "Overview").
See the following documents for short guide to installation of
third-party libraries on different platforms:
- \subpage dev_guides__building_3rdparty_windows
- \subpage dev_guides__building_3rdparty_linux
- \subpage dev_guides__building_3rdparty_osx
2. If you use bare OCCT sources from Git repository or made some changes affecting
CDL files or dependencies of OCCT toolkits, you need to update header files generated
from \ref dev_guides__cdl "CDL", and regenerate build scripts for your environment using WOK.
See \subpage dev_guides__building__wok for details.
Skip to step 3 if you use complete source package (e.g. official OCCT
release) without changes in CDL.
3. Build using your preferred build tool.
- \subpage dev_guides__building__automake "Building on Linux with Autotools"
- \subpage dev_guides__building__cmake "Building with CMake (cross-platform)"
- \subpage dev_guides__building__code_blocks "Building on Mac OS X with Code::Blocks"
- \subpage dev_guides__building__msvc "Building on Windows with MS Visual Studio"
- \subpage dev_guides__building__xcode "Building on Mac OS X with Xcode"
The current version of OCCT can be consulted in the file src/Standard/Standard_Version.hxx

View File

@@ -1,232 +0,0 @@
Building with CMake {#dev_guides__building__cmake}
===================
@tableofcontents
This file describes steps to build OCCT libraries from complete source package
with CMake. CMake is free software that can create GNU Makefiles, KDevelop,
XCode, and Visual Studio project files. Version 2.6 or above of CMake is
required.
If you are building OCCT from bare sources (as in Git repository), or do some
changes affecting CDL files, you need to use WOK to re-generate header files
and build scripts / projects. See \ref dev_guides__building__wok for instructions.
Before building OCCT, you need to install required third-party libraries; see
instructions for your platform in @ref dev_guides__building.
## Decide on location of build and install directories.
The build directory is the one where intermediate files will be created (projects / makefiles, objects, binaries).
The install directory is the one where binaries will be installed after build,
along with header files and resources required for OCCT use in applications.
OCCT CMake scripts assume use of separate build and one install directories
for each configuration (Debug or Release).
It is recommended to separate build and install directories from OCCT source directory, for example:
/user/home/occt/ - sources
/user/home/tmp/occt-build-release - intermediate files (release)
/user/home/occt-install-release - installed binaries (release)
## CMake usage
Run CMake indicating path to OCCT sources ($CASROOT; in previous example
CASROOT equal to /user/home/occt in lin case, and d:/occt in windows case)
and selected build directory (in prev example build directory is
/user/home/tmp/occt-build-release).
It is recommended to use GUI tools provided by CMake: cmake-gui on Windows
and Mac, ccmake on Linux.
### Windows:
@image html /dev_guides/building/cmake/images/cmake_image001.png
@image latex /dev_guides/building/cmake/images/cmake_image001.png
* Specify "main" CMakelists.txt meta-project location by clicking Browse Source (e.g., $CASROOT)
* Specify location (build folder) for Cmake generated project files by clicking Browse Build (e.g., d:/occt/build/win32-vc9-debug) (each cmake configuration of the project uses a specific build directory and a specific directory for installed files. It is recommended to compose names of the binary and install directory from system, bitness, compiler and build type.)
* Configure opens the window with a drop-down list of generators supported by CMake project. Select the required generator (e.g., Visual Studio 2008) and click Finish)
@image html /dev_guides/building/cmake/images/cmake_image002.png
@image latex /dev_guides/building/cmake/images/cmake_image002.png
### Linux:
In the console, change to the build directory and call ccmake with the path to the source directory of the project:
> cd ~/occt/build/debug
> ccmake ~/occt
@image html /dev_guides/building/cmake/images/cmake_image003.png
@image latex /dev_guides/building/cmake/images/cmake_image003.png
Press "c" to configure.
### Mac OS:
Use cmake-gui (Applications -> CMake 2.8-10.app) to generate project files for the chosen build environment (e.g., XCode).
@image html /dev_guides/building/cmake/images/cmake_image004.png
@image latex /dev_guides/building/cmake/images/cmake_image004.png
## OCCT Configuration
The error message which appears at the end of configuration process, informs you about the required variables
which need to be defined. This error will appear until all required variables are defined correctly.
Note: In cmake-gui there is "grouped" option, which groups variables with a common prefix.
### Selection of components to be built
The variables with "BUILD_" prefix allow specifying OCCT components and
configuration to be built:
* BUILD_CONFIGURATION - defines configuration to be built (Release by default).
* BUILD_<MODULE> - specify whether corresponding OCCT module should be
built (all toolkits). Note that even if whole module is not
selected for build, its toolkits used by other toolkits
selected for build will be included automatically.
* BUILD_TOOLKITS - allows including additional toolkits from non-selected
modules (should be list of toolkit names separated by a
space or a semicolon).
* BUILD_SAMPLES - specify whether OCCT MFC samples should be built.
Check variables with "USE_" prefix (USE_FREEIMAGE, USE_GL2PS, USE_TBB, and
USE_OPENCL) if you want to enable use of the corresponding optional 3rd-party
library.
### 3rd-party configuration
### 3rd-party configuration (The variables with 3RDPARTY_ prefix)
If you have 3rd-party libraries in a non-default location
(e.g., on Windows, binaries downloaded from "http://www.opencascade.org/getocc/download/3rdparty/"),
specify 3RDPARTY_DIR variable that points to the folders of 3rdparty products (some or all).
At the next configuration 3rd-party product paths stored in 3RDPARTY_\<PRODUCT\>_DIR variable
will be searched for in 3RDPARTY_DIR directory. If the structure of 3RDPARTY_DIR directory
is the same as adopted in the OCCT, the directory will contain product dir, lib and header files.
Press "Configure" ("c" key for ccmake).
The result of the 3rdparty product search will be recorded in the corresponding variables:
* 3RDPARTY_\<PRODUCT\>_DIR - path to the product directory (with directory name) (e.g., D:/3rdparty/Tcl-8.5.12.0-32)
* 3RDPARTY_\<PRODUCT\>_LIBRARY - path to the .lib libraries (with the library name) (e.g., D:/3rdparty/Tcl-8.5.12.0-32/lib/tcl85.lib). In non-windows case, this variable is the same as 3RDPARTY_\<PRODUCT\>_DLL.
* 3RDPARTY_\<PRODUCT\>_INCLUDE - path to the include directory that contains the required header file (with "include" name) (e.g., D:/3rdparty/Tcl-8.5.12.0-32/include including tcl.h)
* 3RDPARTY_\<PRODUCT\>_DLL - path to the .dll/.so/.dylib library (with the library name) (e.g., D:/3rdparty/Tcl-8.5.12.0-32/bin/tcl85.dll)
The search process is as follows:
1. Common path: 3RDPARTY_DIR
2. Path to particular 3rd-party library: 3RDPARTY_\<PRODUCT\>_DIR
3. Paths to headers and binaries:
1. 3RDPARTY_\<PRODUCT\>_INCLUDE
2. 3RDPARTY_\<PRODUCT\>_LIBRARY
3. 3RDPARTY_\<PRODUCT\>_DLL
If a variable of any level is not defined (empty or \<variable name\>-NOTFOUND)
and the upper level variable is defined, the content of the non-defined variable
will be searched for at the next configuration step. If search process in level 3
does not find the required files, it searches in default places also.
**Note**: the names of searched libraries and header files are hardcoded.
Freetype search process tries to find ft2build.h file in 3RDPARTY_FREETYPE INCLUDE dir
and after that adds "3RDPARTY_FREETYPE_INCLUDE /freetype2" path to common includes if it exists.
Important: If BUILD_CONFIGURATION variable is changed - at the next configuration
3RDPARTY_ variables will be replaced by the search process result, except for the 3RDPARTY_DIR variable.
*Note*: CMake will produce an error after the configuration step until all required variables are defined correctly.
If the search result (include path, or library path, or dll path) does not meet your expectations -
you can change 3RDPARTY_\<PRODUCT\>_DIR variable, clear (if they are not empty)
3RDPARTY_\<PRODUCT\>_DLL, 3RDPARTY_\<PRODUCT\>_INCLUDE_DIR and 3RDPARTY_\<PRODUCT\>_LIBRARY variables
(or clear one of them) and run the configuration process again.
At this time the search will be performed in the new identified directory
and the result will be recorded to empty variables (non-empty variables will not be replaced).
For example, (Linux case) 3RDPARTY_FREETYPE_DIR variable
/PRODUCTS/maintenance/Mandriva2010/freetype-2.3.7
can be changed to
/PRODUCTS/maintenance/Mandriva2010/freetype-2.4.10
and the related variables: 3RDPARTY_FREETYPE_DLL, 3RDPARTY_FREETYPE_INCLUDE_DIR and 3RDPARTY_FREETYPE_LIBRARY will be cleared.
@image html /dev_guides/building/cmake/images/cmake_image005.png
@image latex /dev_guides/building/cmake/images/cmake_image005.png
During configuration process the cleaned variables will be filled with new found values.
###The variables with INSTALL_ prefix:
Define in INSTALL_DIR variable the path where will be placed built OCCT files (libraries, executables and headers).
If INSTALL_\<PRODUCT\> variable is checked - 3rd-party products will be copied to the install directory.
#### At the end of the configuration process "configuring done" message will be shown and the generation process can be started.
## OCCT Generation
This will create makefiles or project files for your build system.
### Windows
Click Generate button and wait until the generation process is finished.
Then the project files will appear in the build folder (e.g., d:/occt/build/win32-vc9-release).
### Linux
When the configuration is complete, start the generation process by pressing "g".
@image html /dev_guides/building/cmake/images/cmake_image006.png
@image latex /dev_guides/building/cmake/images/cmake_image006.png
### Mac OS X
Click Generate button and wait until the generation process is finished.
Then the project files will appear in the build folder (e.g., /Developer/occt/build/XCode).
## OCCT Building
The install folder contains bin, inc, lib and res folders and a script to run DRAWEXE (draw.bat or draw.sh).
"bin" contains executables, DLL (Windows) style shared libraries and pdb-files in OCCT debug version,.
"lib" contains the import parts of DLL libraries.
"inc" contains header files.
"res" contains all required source files for OCCT.
### Windows (Visual studio)
Go to the build folder, start the Visual Studio solution (OCCT.sln) and build it by clicking Build - Build Solution.
When the building process finished, build the INSTALL project
(by default the build solution process skips the building of the INSTALL project) to move the above files to INSTALL_DIR.
For this in the solution explorer right click on the INSTALL project and select Project Only - Build Only INSTALL.
### Linux (make)
Change directory to binary dir and run make command
> make
To copy all libraries, executables and chosen 3rd-party libraries run "make" command with "install" argument
> make install
This command will move the above files to INSTALL_DIR.
### Mac OS X (XCode)
Go to the build folder, start the XCode solution (OCCT.xcodeproj)
and build it by clicking Build -> Build.
Please notice that XCode may have worst responsibility to user actions
due to sources processing at first start.
When the building process finished, build the INSTALL project
(by default the build solution process skips the building of the INSTALL project)
to move the above files to INSTALL_DIR.
Notice that env.sh (configure PATH and DYLD_LIBRARY_PATH environment variables
as well as Draw Harness extra variables) and draw.sh (to launch DRAWEXE) will be created in target directory.
## OCCT project debugging for Visual Studio
Run OCCT.bat from the build directory to start Visual Studio with required environment for debugging.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 102 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 146 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 230 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 188 KiB

View File

@@ -1,64 +0,0 @@
Building with Code::Blocks on Mac OS X {#dev_guides__building__code_blocks}
======================================
This file describes steps to build OCCT libraries from complete source package
on Mac OS X with Code::Blocks.
If you are building OCCT from bare sources (as in Git repository), or do some
changes affecting CDL files, you need to use WOK to re-generate header files
and build scripts / projects. See \ref dev_guides__building__wok for instructions.
Before building OCCT, you need to install required third-party libraries; see
paragraph 1 of \ref dev_guides__building for details.
1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType) in file
custom.sh located in \<OCCT_ROOT_DIR\>. For this:
1.1. Add paths to the includes in variable "CSF_OPT_INC";
1.2. Add paths to the binary libraries in variable "CSF_OPT_LIB64";
All paths should be separated by ":" symbol.
2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage)
in the aforementioned environment variables "CSF_OPT_INC" and
"CSF_OPT_LIB64" from file custom.sh.
If you want to build OCCT without the optional libraries perform the
following steps:
2.1 Disable unnecessary library in custom.sh by setting the corresponding
variable HAVE_\<LIBRARY_NAME\> to "false".
export HAVE_GL2PS=false
2.2 Remove this library from Linker settings in Code::Blocks for each project
that uses it: right click on the required project, choose "Build options",
go to "Linker settings" tab in the opened window , select unnecessary
libraries and click "Delete" button.
3. Open Terminal application
4. Enter \<OCCT_ROOT_DIR\>:
cd \<OCCT_ROOT_DIR\>
5. To start Code::Blocks, run the command /codeblocks.sh
6. To build all toolkits, click "Build->Build workspace" in the menu bar.
To start DRAWEXE, which has been built with Code::Blocks on Mac OS X, perform
the following steps:
1. Open Terminal application
2. Enter \<OCCT_ROOT_DIR\>:
cd \<OCCT_ROOT_DIR\>
3. Run script
./draw_cbp.sh cbp [d]
Option "d" is used if OCCT has been built in Debug mode.

View File

@@ -1,31 +0,0 @@
Building with MS Visual C++ {#dev_guides__building__msvc}
===========================
This file describes steps to build OCCT libraries from complete source
archive on Windows with MS Visual C++.
If you are building OCCT from bare sources (as in Git repository), or do some
changes affecting CDL files, you need to use WOK to re-generate header files
and build scripts / projects. See \ref dev_guides__building__wok for instructions.
Before building OCCT, you need to install required third-party libraries; see
paragraph 1 of \ref dev_guides__building for instructions.
1. Edit file custom.bat to define environment:
- VCVER - version of Visual Studio (vc8, vc9, vc10, vc11 or vc12),
and relevant VCVARS path
- ARCH - architecture (32 or 64), affects only PATH variable for execution
- HAVE_* - flags to enable or disable use of optional third-party products
- CSF_OPT_* - paths to search for includes and binaries of all used
third-party products
2. Launch msvc.bat to start Visual Studio with all necessary environment
variables defined.
Note: the MSVC project files are located in folders adm\\msvc\\vc[9-12].
Binaries are produced in win32 or win64 folders.
3. Build with Visual Studio
To start DRAW, launch draw.bat.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 168 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 270 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 157 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 194 KiB

View File

@@ -1,162 +0,0 @@
Using WOK {#dev_guides__building__wok}
=========
@tableofcontents
\ref dev_guides__wok "WOK" is a legacy build environment for Open CASCADE Technology.
It is required for generation of header files for classes defined with
@ref dev_guides__cdl "CDL" ("Cascade Definition Language").
Also tools for generation of project files for other build systems, and OCCT
documentation, are integrated to WOK.
WOK thus is needed in the following situations:
- Building from OCCT sources from Git repository (do not contain generated files)
- Building after some changes made in CDL files
Before installing and using WOK, make sure that you have installed a compiler
(it is assumed that it is Visual Studio on Windows or gcc on Linux and MacOS)
and third-party components required for building OCCT.
@section wok1 Installing WOK
Download the latest version of binary distribution WOK from http://dev.opencascade.org/index.php?q=home/resources
@subsection wok11 Windows
Run the installer. You will be prompted to read and accept the OCCT Public License to proceed:
@image html /dev_guides/building/wok/images/wok_image001.png
@image latex /dev_guides/building/wok/images/wok_image001.png
Click Next and proceed with the installation.
At the end of the installation you will be prompted to specify the version and the location of Visual Studio to be used, and the location of third-party libraries:
@image html /dev_guides/building/wok/images/wok_image002.png
@image latex /dev_guides/building/wok/images/wok_image002.png
You can change these settings at any time later. For this click on the item "Customize environment (GUI tool)" in the WOK group in the Windows Start menu.
The shortcuts from this group provide two ways to run WOK:
* In command prompt window ("WOK TCL shell").
* In Emacs editor ("WOK Emacs"). Using Emacs is convenient if you need to work within WOK environment.
By default WOK installer creates a WOK factory with name "LOC" within workshop "dev" (WOK path :LOC:dev).
@subsection wok12 Linux
* Unpack the .tgz archive containing WOK distributive into an installation directory \<WOK_INSTALL_DIR\>.
* Perform the following commands assuming that you have unpacked WOK distributive archive into \<WOK_INSTALL_DIR\>:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
cd \<WOK_INSTALL_DIR\>/site
wok_confgui.sh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Define all necessary paths to third-party products in the dialog window:
@image html /dev_guides/building/wok/images/wok_image003.png
@image latex /dev_guides/building/wok/images/wok_image003.png
* Run the following commands to create WOK LOC factory:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
cd \<WOK_INSTALL_DIR\>/site
wok_init.sh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Your installation procedure is over. To run WOK use one the following commands:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
cd \<WOK_INSTALL_DIR\>/site
wok_emacs.sh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
cd \<WOK_INSTALL_DIR\>/site
wok_tclsh.sh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsection wok13 Mac OS X
* In the Finder double click on wokSetup.dmg file. This will open a new window. Drag and drop "wokSetup" folder from this window at the location in the Finder where you want to install WOK, i.e. \<WOK_INSTALL_DIR\>.
* Browse in the Finder to the folder \<WOK_INSTALL_DIR\>/site and double click on WokConfig. This will open a window with additional search path settings. Define all necessary paths to third-party products in the dialog window:
@image html /dev_guides/building/wok/images/wok_image004.png
@image latex /dev_guides/building/wok/images/wok_image004.png
* Run the following commands to create WOK LOC factory:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
cd \<WOK_INSTALL_DIR\>/site
wok_init.sh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Your installation procedure is over. To run WOK in Emacs navigate in the Finder to the folder \<WOK_INSTALL_DIR\>/site and double click on WokEmacs.
@section wok2 Initialization of Workbench
To start working with OCCT, clone the OCCT Git repository from the server (see http://dev.opencascade.org/index.php?q=home/resources for details) or unpack the source archive.
Then create a WOK workbench (command wcreate) setting its Home to the directory, where the repository is created ($CASROOT variable). The workbench should have the same name as that directory.
For example, assuming that OCCT repository has been cloned into D:/occt folder:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
LOC:dev> wcreate occt -DHome=D:/occt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note: $CASROOT is equal to D:/occt now
Then you can work with this workbench using normal WOK functionality (wprocess, umake, etc.; see 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.
@section wok3 Generation of building projects
Use command wgenproj in WOK to generate derived headers, source and building projects files:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
LOC:dev> wokcd occt
LOC:dev:occt> wgenproj [ -target=<TARGET> ] [ -no_wprocess ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TARGET:
* vc8 - Visual Studio 2005
* vc9 - Visual Studio 2008
* vc10 - Visual Studio 2010
* vc11 - Visual Studio 2012
* cbp - CodeBlocks
* cmake - CMake
* amk - AutoMake
* xcd - Xcode
-no_wprocess - skip generation of derived headers and source files
Note that this command takes several minutes to complete at the first call.
Re-execute this step to generate derived headers, source and building projects files if some CDL files in OCCT have been modified (either by you directly, or due to updates in the repository). Note that in some cases WOK may fail to update correctly; in such case remove sub-directories drv and .adm and repeat the command.
To regenerate derived headers and source files without regeneration of projects use command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
LOC:dev> wokcd occt
LOC:dev:occt> wprocess -DGroups=Src,Xcpp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The generated building project has been placed into $CASROOT/adm folder:
* for vc8 - $CASROOT/adm/msvc/vc8
* for vc9 - $CASROOT/adm/msvc/vc9
* for vc10 - $CASROOT/adm/msvc/vc10
* for vc11 - $CASROOT/adm/msvc/vc11
* for cbp - $CASROOT/adm/\<OS\>/cbp
* for cmake - $CASROOT/adm/cmake
* for amk - $CASROOT/adm/lin/amk
* xcd - $CASROOT/adm/\<OS\>/xcd
@section wok4 Generation of documentation
Use command wgendoc in WOK to generate reference documentation:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
:LOC:dev> wokcd occt
:LOC:dev:occt> wgendoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following options can be used:
* -wb=< workbench name > the name of OCCT workbench (the current one by default);
* -m=< list of modules > the list of modules that will be contained in the documentation;
* -outdir=< path > the output directory for the documentation;
* -chm the option to generate CHM file;
* -hhc=< path > the path to HTML Help Compiler (hhc.exe) or equivalent;
* -qthelp=< path > the option to generate Qt Help file, it is necessary to specify the path to qthelpgenerator executable;
* -doxygen=< path > the path to Doxygen executable
* -dot=< path > the path to GraphViz dot executable

View File

@@ -1,71 +0,0 @@
Building with Xcode {#dev_guides__building__xcode}
===================
This file describes steps to build OCCT libraries from complete source package
on Mac OS X with Xcode.
If you are building OCCT from bare sources (as in Git repository), or do some
changes affecting CDL files, you need to use WOK to re-generate header files
and build scripts / projects. See \ref dev_guides__building__wok for instructions.
Before building OCCT, you need to install required third-party libraries; see
paragraph 1 of \ref dev_guides__building for details.
1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType)
in file custom.sh located in \<OCCT_ROOT_DIR\>. For this:
1.1. Add paths to the includes in variable "CSF_OPT_INC";
1.2. Add paths to the binary libraries in variable "CSF_OPT_LIB64";
All paths should be separated by ":" symbol.
2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage)
in the aforementioned environment variables "CSF_OPT_INC" and
"CSF_OPT_LIB64" from file custom.sh.
If you want to build OCCT without the optional libraries perform the
following steps:
2.1 Disable unnecessary library in custom.sh by setting the corresponding
variable HAVE_<LIBRARY_NAME> to "false".
export HAVE_GL2PS=false
2.2 Remove this library from Project navigator in Xcode for each project that
uses it: choose the required project, right click on the unnecessary
library and select "Delete" button.
3. Open Terminal application.
4. Enter \<OCCT_ROOT_DIR\>:
cd \<OCCT_ROOT_DIR\>
5. To start Xcode, run the command /xcode.sh
6. To build a certain toolkit, select it in "Scheme" drop-down list in Xcode
toolbar, press "Product" in the menu and click "Build" button.
To build the entire OCCT, create a new empty project (select "File ->
New -> Project -> "Empty project" in the menu. Input the project name,
e.g. "OCCT", click "Next" and "Create" buttons). Drag and drop the "OCCT"
folder in the created "OCCT" project in the Project navigator. Select
"File -> New -> Target -> Aggregate" in the menu. Enter the project name
(e.g. "OCCT") and click "Finish". The "Build Phases" tab will open.
Click "+" button to add the necessary toolkits to the target project.
It is possible to select all toolkits by pressing "Command+A" combination.
To start DRAWEXE, which has been built with Xcode on Mac OS X, perform the following steps:
1. Open Terminal application
2. Enter \<OCCT_ROOT_DIR\>:
cd \<OCCT_ROOT_DIR\>
3. Run script
./draw_cbp.sh xcd [d]
Option "d" is used if OCCT has been built in Debug mode.

File diff suppressed because it is too large Load Diff

Binary file not shown.

Before

Width:  |  Height:  |  Size: 96 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 91 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 138 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 77 KiB

View File

@@ -1,916 +0,0 @@
Coding Rules {#dev_guides__coding_rules}
======================================
@tableofcontents
@section OCCT_RULES_SECTION_1 Introduction
The purpose of this document is to define and formalize one style of programming for developers working on Open CASCADE Technology.
The establishment of a common style facilitates understanding and maintaining code developed by more than one programmer as well as making it easier for several people to co-operate in the development of the same framework.
In addition, following a common programming style enables the construction of tools that incorporate knowledge of these standards to help in the programming task.
Using a consistent coding style throughout a particular module, package, or project is important because it allows people other than the author, and the author himself, to easily understand and (hopefully) maintain the code.
Most programming styles are somewhat arbitrary, and this one is no exception. Some guidelines have been excerpted from the public domain of widely accepted practices.
This suggests that the guide will continue to evolve over time as new ideas and enhancements are added.
@subsection OCCT_RULES_SECTION_1_1 Scope of the rules in this document
Rules in this document was written for C++ code.
However, with minor exceptions due to language restrictions, them should be applied to any sources in Open CASCADE Technology framework, including:
- C/C++
- GLSL programs
- OpenCL kernels
- TCL scripts and test cases
@section OCCT_RULES_SECTION_2 Naming Conventions
@subsection OCCT_RULES_SECTION_2_1 General naming rules
The names considered in this section are mainly those which compound the interface to Open CASCADE Technology libraries as well as source code itself.
### International language [MANDATORY]
All names are composed of English words and their abbreviations.
Open CASCADE Technology is an open source available for international community.
### Suggestive names
Names should be suggestive or, at least, contain a suggestive part.
Currently, there is no exact rule that would define how to generate suggestive names. However, usually names given to toolkits, packages, classes and methods are suggestive. Here are several examples:
- Packages containing words Geom or Geom2d in their names are related to geometrical data and operations.
- Packages containing words TopoDS or BRep in their names are related to topological data and operations.
- In OCAF, packages that define transient, persistent data classes and drivers to map between them, have similar names prefixed by 'T', 'P', and 'M' correspondingly (e.g. TDocStd, PDocStd, MDocStd).
- Packages ending with ...Test define Draw Harness plugins.
- Methods starting with Get... and Set... are usually responsible for (accordingly) retrieving/storing some data.
### Related names
Names that define logically connected functionality should have the same prefix (start with the same letters) or, at least, have any other common part in them.
As an example the method GetCoord can be given. It returns a triple of real values and is defined for directions, vectors and points. The logical connection is obvious.
### Camel Case style
Camel Case style is preferred for names.
For example:
~~~~~{.cpp}
Standard_Integer awidthofbox; // this is bad
Standard_Integer width_of_box; // this is bad
Standard_Integer aWidthOfBox; // this is OK
~~~~~
@subsection OCCT_RULES_SECTION_2_2 Names of development units
Usually unit (e.g. package) is a set of classes, methods, enumerations or any other sources implementing certain common functionality which, to the certain extent, is self contained and independent from other parts of library.
### Underscores in units names [MANDATORY]
Names of units should not contain underscores, except cases where usage of underscores is allowed explicitly.
Usually names of files consisting Open CASCADE Technology are constructed according to the rules defined in the appropriate sections of this document.
### File names extensions [MANDATORY]
The following extensions should be used for source files, depending on their type:
.cdl - CDL declaration files
.cxx - C++ source files
.hxx - C++ header files
.lxx - headers with definitions of inline methods (CDL packages)
@subsection OCCT_RULES_SECTION_2_3 Names of toolkits
The following rules are usually used in naming of toolkits:
### Prefix for toolkits names [MANDATORY]
Toolkits names are prefixed by TK, followed by suggestive part of name explaining the domain of functionality covered by the toolkit (e.g. TKOpenGl).
### Names of classes
Usually source files located in the unit have names that start from the name of the unit, separated from remaining part of file name (if any) by underscore "_".
For instance, names of files containing sources of C++ classes are constructed according to the following template.
### Naming of C++ class files
The following template should be used for names of files containing sources of C++ classes:
<unit-name>_<class-name>.cxx (.hxx, .cdl etc.)
Files that contain sources related to whole unit are called by the name of unit with appropriate extension.
### Names of functions
The term 'function' here is defined as:
- Any class method
- Any package method
- Any non-member procedure or function
It is preferred to name public methods from upper case, while protected and private methods from low case.
~~~~~{.cpp}
class MyPackage_MyClass
{
public:
Standard_Integer Value() const;
void SetValue (const Standard_Integer theValue);
private:
void setIntegerValue (const Standard_Integer theValue);
};
~~~~~
@subsection OCCT_RULES_SECTION_2_4 Names of variables
There are several rules that describe currently accepted practice used for naming variables.
### Naming of variables
Name of variable should not conflict with the global names (packages, macros, functions, global variables etc.), either existing or possible.
The name of variable should not start with underscore(s).
See the following examples:
~~~~~{.cpp}
Standard_Integer Elapsed_Time = 0; // this is bad - possible class name
Standard_Integer gp = 0; // this is bad - existing package name
Standard_Integer aGp = 0; // this is OK
Standard_Integer _KERNEL = 0; // this is bad
Standard_Integer THE_KERNEL = 0; // this is OK
~~~~~
### Names of function parameters
The name of a function (procedure, class method) parameter should start with 'the' followed by the rest of the name starting with capital letter.
See the following examples:
~~~~~{.cpp}
void Package_MyClass::MyFunction (const gp_Pnt& p); // this is bad
void Package_MyClass::MyFunction (const gp_Pnt& theP); // this is OK
void Package_MyClass::MyFunction (const gp_Pnt& thePoint); // this is preferred
~~~~~
### Names of class member variables
The name of a class member variable should start with 'my' followed by the rest of the name (rule for suggestive names applies) starting with capital letter.
See the following examples:
~~~~~{.cpp}
Standard_Integer counter; // This is bad
Standard_Integer myC; // This is OK
Standard_Integer myCounter; // This is preferred
~~~~~
### Names of global variables
It is strongly recommended to avoid defining any global variables.
However, as soon as global variable is necessary, the following rule applies.
Global variable name should be prefixed by the name of a class or a package where it is defined followed with '_my'.
See the following examples:
~~~~~{.cpp}
Standard_Integer MyPackage_myGlobalVariable = 0;
Standard_Integer MyPackage_MyClass_myGlobalVariable = 0;
~~~~~
Static constants within the file should be spelled upper-case and started with 'THE_' prefix:
~~~~~{.cpp}
namespace
{
static const Standard_Real THE_CONSTANT_COEF = 3.14;
};
~~~~~
### Names of local variables
Local variable name should be constructed in such way that it can be distinguished from the name of a function parameter, a class member variable and a global variable.
It is preferred to prefix local variable names with 'a' and 'an' (also 'is', 'to' and 'has' for Boolean variables).
See the following examples:
~~~~~{.cpp}
Standard_Integer theI; // this is bad
Standard_Integer i; // this is bad
Standard_Integer index; // this is bad
Standard_Integer anIndex; // this is OK
~~~~~
### Avoid dummy names
Avoid dummy names like I, j, k. Such names are meaningless and easy to mix up.
Code becomes more and more complicated when such dummy names used multiple times in code with different meaning, in cycles with different iteration ranges and so on.
See the following examples for preferred style:
~~~~~{.cpp}
void Average (const Standard_Real** theArray,
Standard_Integer theRowsNb,
Standard_Integer theRowLen,
Standard_Real& theResult)
{
theResult = 0.0;
for (Standard_Integer aRow = 0; aRow < aRowsNb; ++aRow)
{
for (Standard_Integer aCol = 0; aCol < aRowLen; ++aCol)
{
theResult += theArray[aRow][aCol];
}
theResult /= Standard_Real(aRowsNb * aRowLen);
}
}
~~~~~
@section OCCT_RULES_SECTION_3 Formatting rules
In order to improve the open source readability and, consequently, maintainability, the following set of rules is applied.
### International language [MANDATORY]
All comments in all sources must be in English.
### Line length
In all sources try not to exceed 120 characters limit of line length.
### C++ style comments
Prefer C++ style comments in C++ sources.
### Commenting out unused code
Delete unused code instead of commenting it or using #define.
### Indentation in sources [MANDATORY]
Indentation in all sources should be set to two space characters.
Use of tabulation characters for indentation is disallowed.
### Separating spaces
Punctuation rules follow the rules of English.
C/C++ reserved words, commas, colons and semicolons should be followed by a space character if they are not at the end of line.
There should be no space characters after '(' and before ')'. Closing and opening brackets should be separated by a space character.
For better readability it is also recommended to surround conventional operators by a space character. See the following examples:
~~~~~{.cpp}
while (true) // NOT: while( true ) ...
{
DoSomething (theA, theB, theC, theD); // NOT: DoSomething(theA,theB,theC,theD);
}
for (anIter = 0; anIter < 10; ++anIter) // NOT: for (anIter=0;anIter<10;++anIter){
{
theA = (theB + theC) * theD; // NOT: theA=(theB+theC)*theD
}
~~~~~
### Separate logical blocks
Separate logical blocks of code with one blank line and comments.
See the following example:
~~~~~{.cpp}
// check arguments
Standard_Integer anArgsNb = argCount();
if (anArgsNb < 3 || isSmthInvalid)
{
return THE_ARG_INVALID;
}
// read and check header
...
...
// do our job
...
...
~~~~~
Notice that multiple blank lines should be avoided.
### Separate function bodies [MANDATORY]
Use function descriptive blocks to separate function bodies from each other.
Each descriptive block should contain at least a function name and description of purpose.
See the following example:
~~~~~{.cpp}
// ----------------------------------------------
// function : TellMeSmthGood
// purpose : Gives me good news
// ----------------------------------------------
void TellMeSmthGood()
{
...
}
// ----------------------------------------------
// function : TellMeSmthBad
// purpose : Gives me bad news
// ----------------------------------------------
void TellMeSmthBad()
{
...
}
~~~~~
### Block layout [MANDATORY]
Figure brackets '{', '}' and each operator (for, if, else, try, catch) should be on dedicated line.
General block should have layout similarly to the following:
~~~~~{.cpp}
while (expression)
{
...
}
~~~~~
Entering block increases and leaving block decreases indentation to one tabulation.
### Single-line operators
Single-line conditional operator (if, while, for etc.) can be written without brackets on the following line.
~~~~~{.cpp}
if (!myIsInit) return Standard_False; // bad
if (thePtr == NULL) // OK
return Standard_False;
if (!theAlgo.IsNull()) // preferred
{
DoSomething();
}
~~~~~
Code on the same line is less convenient for debugging.
### Use alignment
Use alignment wherever it enhances readability. See the following example:
~~~~~{.cpp}
MyPackage_MyClass anObject;
Standard_Real aMinimum = 0.0;
Standard_Integer aVal = theVal;
switch (aVal)
{
case 0: computeSomething(); break;
case 12: computeSomethingElse (aMinimum); break;
case 3:
default: computeSomethingElseYet(); break;
}
~~~~~
### Indentation of comments
Comments should be indented similar to the code which they refer to or can be on the same line if they are short.
Text should be delimited with single space character from slash.
See the following example:
~~~~~{.cpp}
while (expression) //bad comment
{
// this is a long multi-line comment
// which is really required
DoSomething(); // maybe, enough
DoSomethingMore(); // again
}
~~~~~
### Early return statement
Prefer early return condition rather than collecting indentations.
Better write like this:
~~~~~{.cpp}
Standard_Integer ComputeSumm (const Standard_Integer* theArray,
const Standard_Size theSize)
{
Standard_Integer aSumm = 0;
if (theArray == NULL || theSize == 0)
{
return 0;
}
... computing summ ...
return aSumm;
}
~~~~~
rather than:
~~~~~{.cpp}
Standard_Integer ComputeSumm (const Standard_Integer* theArray,
const Standard_Size theSize)
{
Standard_Integer aSumm = 0;
if (theArray != NULL && theSize != 0)
{
... computing summ ...
}
return aSumm;
}
~~~~~
to improve readability and reduce unnecessary indentation depth.
### Trailing spaces
Trailing spaces should be removed when possible.
Spaces at end of line are useless and do not affect functionality.
### Headers order
Split into groups: system headers, per framework headers, project headers; sort includes list alphabetically.
This rule can improve readability, allows detection of useless header's multiple inclusions and makes 3rd-party dependencies clearly visible.
~~~~~{.cpp}
// system headers
#include <iostream>
#include <windows.h>
// Qt headers
#include <QDataStream>
#include <QString>
// OCCT headers
#include <gp_Pnt.hxx>
#include <gp_Vec.hxx>
#include <NCollection_List.hxx>
~~~~~
@section OCCT_RULES_SECTION_4 Documentation rules
The source code is one of the most important references for documentation.
The comments in the source code should be complete enough to allow understanding of that code, and to serve as basis for other documents.
The main reasons why comments are regarded as documentation and should be maintained are:
- The comments are easy to reach - they are always together with source code
- It's easy to update description in the comment when source is modified
- The source itself represents a good context to describe various details that would require much more explanations in separate document
- As a summary, this is the most cost-effective documentation
The comments should be compatible with Doxygen tool for automatic documentation generation (thus should use compatible tags).
### Documenting classes [MANDATORY]
Each class should be documented in its header file (.hxx or .cdl).
The comment should give enough details for the reader to understand the purpose of the class and main way of work with it.
### Documenting class methods [MANDATORY]
Each class or package method should be documented in the header file (.hxx or .cdl).
The comment should explain the purpose of the method, its parameters, and returned value(s).
Accepted style is:
@verbatim
//! Method computes the square value.
//! @param theValue the input value
//! @return squared value
Standard_Export Standard_Real Square (Standard_Real theValue);
@endverbatim
### Documenting C/C++ sources
It is very desirable to put comments in the C/C++ sources of the package/class.
They should be detailed enough to allow any person to understand what does each part of code, and get familiar with it.
It is recommended to comment all static functions (like methods in headers), and at least each 10-100 lines of the function bodies.
There are also some rules that define how comments should be formatted, see section "Formatting Rules".
Following these rules is important for good comprehension of the comments;
moreover it makes possible to automatically generate user-oriented documentation directly from commented sources.
@section OCCT_RULES_SECTION_5 Application design
The following set of rules defines the common style which should be applied by any developer contributing to the open source.
### Allow for possible inheritance
Try to design general classes (objects) keeping possible inheritance in mind.
This rule means that making possible extensions of your class the user should not encounter with problems of private implementations.
Try to use protected members and virtual methods wherever you expect extensions in the future.
### Avoid friend declarations
Avoid using 'friend' classes or functions except some specific cases (ex., iteration) 'Friend' declarations increase coupling.
### Set/get methods
Avoid providing set/get methods for all fields of the class.
Intensive set/get functions break down encapsulation.
### Hiding virtual functions [MANDATORY]
Avoid hiding a base class virtual function by a redefined function with a different signature.
Most of the compilers issue warning on this.
### Avoid mixing error reporting strategies
Try not to mix different error indication/handling strategies (exceptions or returned values) on the same level of an application.
### Minimize compiler warnings [MANDATORY]
When compiling the source pay attention to and try to minimize compiler warnings.
### Avoid unnecessary inclusion
Try to minimize compilation dependencies by removing unnecessary inclusion.
@section OCCT_RULES_SECTION_6 General C/C++ rules
This section defines rules for writing portable and maintainable C/C++ source code.
### Wrapping of global variables [MANDATORY]
Use package or class methods returning reference to wrap global variables to reduces possible name space conflicts.
### Avoid private members
Use 'protected' members instead of 'private' wherever reasonable to enable future extensions.
Use 'private' fields if future extensions should be disabled.
### Constants and inlines over defines [MANDATORY]
Use constant variables (const) and inline functions instead of defines (#define).
### Avoid explicit numerical values [MANDATORY]
Avoid usage of explicit numeric values. Use named constants and enumerations instead.
Magic numbers are badly to read and maintain.
### Three mandatory methods
A class with any of (destructor, assignment operator, copy constructor) usually needs all of them.
### Virtual destructor
A class with virtual function(s) ought to have a virtual destructor.
### Default parameter value
Do not redefine a default parameter value in an inherited function.
### Use const modifier
Use const modifier wherever possible (functions parameters, return values etc.)
### Usage of goto [MANDATORY]
Avoid goto statement except the cases where it is really needed.
### Declaring variable in for() header
Declaring cycle variable in the header of the for() statement if not used out of cycle.
~~~~~{.cpp}
Standard_Real aMinDist = Precision::Infinite();
for (NCollection_Sequence<gp_Pnt>::Iterator aPntIter (theSequence);
aPntIter.More(); aPntIter.Next())
{
aMinDist = Min (aMinDist, theOrigin.Distance (aPntIter.Value()));
}
~~~~~
### Condition statements within zero
Avoid usage of C-style comparison for non-boolean variables:
~~~~~{.cpp}
void Function (Standard_Integer theValue,
Standard_Real* thePointer)
{
if (!theValue) // bad style - ambiguous logic
{
DoSome();
}
if (theValue == 0) // OK
{
DoSome();
}
if (thePointer != NULL) // OK, predefined NULL makes pointer comparison cleaner to reader
{ // (nullptr should be used instead as soon as C++11 will be available)
DoSome2();
}
}
~~~~~
@section OCCT_RULES_SECTION_7 Portability issues
This chapter contains rules that are critical for cross-platform portability.
### Ensure code portability [MANDATORY]
It is required that source code must be portable to all platforms listed in the official 'Technical Requirements'.
The term 'portable' here means 'able to be built from source'.
The C++ source code should meet C++03 standard.
Any usage of compiler-specific features or further language versions (C++11, until all major compliers on all supported platforms do not implement all it features)
should be optional (escaped with appropriate preprocessor checks) and non-exclusive (alternative implementation should be provided, compatible with other compilers).
### Avoid usage of global variables [MANDATORY]
Avoid usage of global variables. Usage of global variables may cause problems of accessing them from another shared library.
Instead of global variables, use global (package or class) functions that return reference to static variable local to this function.
Another possible problem is the order of initialization of global variables defined in various libraries that may differ depending on platform, compiler and environment.
### Avoid explicit basic types
Avoid explicit usage of basic types (int, float, double etc.), use Open CASCADE Technology types (from package Standard - see Standard_Integer, Standard_Real, Standard_ShortReal, Standard_Boolean, Standard_CString and others) or specific typedef instead.
### Use sizeof() to calculate sizes [MANDATORY]
Do not assume sizes of types. Use sizeof() instead to calculate sizes.
### Empty line at end of file [MANDATORY]
In accordance with C++03 standard source files should be trailed by empty line.
It is recommended to follow this rule for any plain text files for consistency and for correct work of git difference tools.
@section OCCT_RULES_SECTION_8 Stability issues
The rules listed in this chapter are important for stability of the programs that use Open CASCADE Technology libraries.
### OSD::SetSignal() to catch exceptions
When using Open CASCADE Technology in an application, make sure to call OSD::SetSignal() function when the application is initialized.
This will install C handlers for run-time interrupt signals and exceptions,
so that low-level exceptions (such as access violation, division by zero etc.) will be redirected to C++ exceptions
(that use try {...} catch (Standard_Failure) {...} blocks).
The above rule is especially important for robustness of modeling algorithms.
### Cross-referenced handles
Take care about cycling of handled references to avoid chains which will never be freed.
For that purpose, use a pointer at one (subordinate) side. See the following example:
In MyPackage.cdl:
class MyFirstHandle;
class MySecondHandle;
pointer MySecondPointer to MySecondHandle;
...
In MyPackage_MyFirstHandle.cdl:
class MyFirstHandle from MyPackage
...
is
...
SetSecondHandleA (me: mutable; theSecond: MySecondHandle from MyPackage);
SetSecondHandleB (me: mutable; theSecond: MySecondHandle from MyPackage);
...
fields
...
mySecondHandle : MySecondHandle from MyPackage;
mySecondPointer : MySecondPointer from MyPackage;
...
end MyFirstHandle from MyPackage;
In MyPackage_MySecondHandle.cdl:
class MySecondHandle from MyPackage
...
is
...
SetFirstHandle (me: mutable; theFirst: MyFirstHandle from MyPackage);
...
fields
...
myFirstHandle : MyFirstHandle from MyPackage;
...
end MySecondHandle from MyPackage;
In C++ code:
~~~~~{.cpp}
void MyFunction()
{
Handle(MyPackage_MyFirstHandle) anObj1 = new MyPackage_MyFirstHandle();
Handle(MyPackage_MySecondHandle) anObj2 = new MyPackage_MySecondHandle();
Handle(MyPackage_MySecondHandle) anObj3 = new MyPackage_MySecondHandle();
anObj1->SetSecondHandleA(anObj2);
anObj1->SetSecondHandleB(anObj3);
anObj2->SetFirstHandle(anObj1);
anObj3->SetFirstHandle(anObj1);
// memory is not freed here !!!
anObj1.Nullify();
anObj2.Nullify();
// memory is freed here
anObj3.Nullify();
}
~~~~~
### C++ memory allocation
In C++ use new and delete operators instead of malloc() and free().
Try not to mix different memory allocation techniques.
### Match new and delete [MANDATORY]
Use the same form of new and delete.
~~~~~{.cpp}
aPtr1 = new TypeA[n]; ... ; delete[] aPtr1;
aPtr2 = new TypeB(); ... ; delete aPtr2;
aPtr3 = Standard::Allocate (4096); ... ; Standard::Free (aPtr3);
~~~~~
### Methods managing dynamical allocation [MANDATORY]
Define a destructor, a copy constructor and an assignment operator for classes with dynamically allocated memory.
### Uninitialized variables [MANDATORY]
Every variable should be initialized.
~~~~~{.cpp}
Standard_Integer aTmpVar1; // bad
Standard_Integer aTmpVar2 = 0; // OK
~~~~~
Uninitialized variables might be kept only within performance-sensitive code blocks and only when their initialization is *guarantied* by following code.
### Do not hide global new
Avoid hiding the global new operator.
### Assignment operator
In operator=() assign to all data members and check for assignment to self.
### Float comparison
Don't check floats for equality or non-equality; check for GT, GE, LT or LE.
~~~~~{.cpp}
if (Abs (theFloat1 - theFloat2) < theTolerance)
{
DoSome();
}
~~~~~
Package 'Precision' provides standard values for SI units and widely adopted by existing modeling algorithms:
- Precision::Confusion() for lengths in meters
- Precision::Angular() for angles in radians
as well as definition of infinity values within sanity range of double precision:
- Precision::Infinite()
- Precision::IsInfinite()
- Precision::IsPositiveInfinite()
- Precision::IsNegativeInfinite()
### Non-indexed iteration
Avoid usage of iteration over non-indexed collections of objects.
If such iteration is used, make sure that the result of the algorithm does not depend on order.
Since the order of iteration is unpredictable in this case, it frequently leads to different behavior of the application from one run to another,
thus embarrassing the debugging process.
It mostly concerns mapped objects for which pointers are involved in calculating the hash function.
For example, the hash function of TopoDS_Shape involves the address of TopoDS_TShape object.
Thus the order of the same shape in the TopTools_MapOfShape will vary in different sessions of the application.
### Do not throw in destructors
Do not throw from within destructor.
### Assigning to reference [MANDATORY]
Avoid possible assignments of the temporary object to a reference.
Different behavior for different compiler of different platforms.
@section OCCT_RULES_SECTION_9 Performance issues
These rules define the ways of avoiding possible loss of performance caused by ineffective programming.
### Class fields alignment
In a class, declare its fields in the decreasing order of their size for better alignment.
Generally, try to reduce misaligned accesses since they impact the performance (for example, on Intel machines).
### Fields initialization order [MANDATORY]
List class data members in the constructor's initialization list in the order they are declared.
~~~~~{.cpp}
class MyPackage_MyClass
{
public:
MyPackage_MyClass()
: myPropertyA (1),
myPropertyB (2) {}
// NOT
// : myPropertyB (2),
// myPropertyA (1) {}
private:
Standard_Integer myPropertyA;
Standard_Integer myPropertyB;
};
~~~~~
### Initialization over assignment
In class constructors prefer initialization over assignment.
~~~~~{.cpp}
MyPackage_MyClass()
: myPropertyA (1) // preferred
{
myPropertyB = 2; // not recommended
}
~~~~~
### Optimize caching
When programming procedures with extensive memory access, try to optimize them in terms of cache behavior.
Here is an example of how cache behavior can be impact:
On x86 this code
~~~~~{.cpp}
Standard_Real anArray[4096][2];
for (Standard_Integer anIter = 0; anIter < 4096; ++anIter)
{
anArray[anIter][0] = anArray[anIter][1];
}
~~~~~
is more efficient than
~~~~~{.cpp}
Standard_Real anArray[2][4096];
for (Standard_Integer anIter = 0; anIter < 4096; ++anIter)
{
anArray[0][anIter] = anArray[1][anIter];
}
~~~~~
since linear access (above) does not invalidate cache too often.
@section OCCT_RULES_SECTION_10 Examples
Here is C++ source file sample:
@verbatim
//! Sample documented class
class Package_Class
{
public: //! @name public methods
//! Method computes the square value.
//! @param theValue the input value
//! @return squared value
Standard_Export Standard_Real Square (const Standard_Real theValue);
private: //! @name private methods
//! Auxiliary method
void increment();
private: //! @name private fields
Standard_Integer myCounter; //!< usage counter
};
@endverbatim
~~~~~{.cpp}
#include <Package_Class.hxx>
// ==========================================================
// function : Square
// purpose : Method computes the square value
// ==========================================================
Standard_Real Package_Class::Square (const Standard_Real theValue)
{
increment();
return theValue * theValue;
}
// ==========================================================
// function : increment
// purpose :
// ==========================================================
void Package_Class::increment()
{
++myCounter;
}
~~~~~
TCL script for Draw Harness:
~~~~~{.tcl}
# show fragments (solids) in shading with different colors
proc DisplayColored {theShape} {
set aSolids [uplevel #0 explode $theShape so]
set aColorIter 0
set THE_COLORS {red green blue1 magenta1 yellow cyan1 brown}
foreach aSolIter $aSolids {
uplevel #0 vdisplay $aSolIter
uplevel #0 vsetcolor $aSolIter [lindex $THE_COLORS [expr [incr aColorIter] % [llength $THE_COLORS]]]
uplevel #0 vsetdispmode $aSolIter 1
uplevel #0 vsetmaterial $aSolIter plastic
uplevel #0 vsettransparency $aSolIter 0.5
}
}
# load modules
pload MODELING VISUALIZATION
# create boxes
box bc 0 0 0 1 1 1
box br 1 0 0 1 1 2
compound bc br c
# show fragments (solids) in shading with different colors
vinit View1
vclear
vaxo
vzbufftrihedron
DisplayColored c
vfit
vdump $imagedir/${casename}.png 512 512
~~~~~
GLSL program:
~~~~~{.fs}
vec3 Ambient; //!< Ambient contribution of light sources
vec3 Diffuse; //!< Diffuse contribution of light sources
vec3 Specular; //!< Specular contribution of light sources
//! Computes illumination from light sources
vec4 ComputeLighting (in vec3 theNormal,
in vec3 theView,
in vec4 thePoint)
{
// clear the light intensity accumulators
Ambient = occLightAmbient.rgb;
Diffuse = vec3 (0.0);
Specular = vec3 (0.0);
vec3 aPoint = thePoint.xyz / thePoint.w;
for (int anIndex = 0; anIndex < occLightSourcesCount; ++anIndex)
{
int aType = occLight_Type (anIndex);
if (aType == OccLightType_Direct)
{
directionalLight (anIndex, theNormal, theView);
}
else if (aType == OccLightType_Point)
{
pointLight (anIndex, theNormal, theView, aPoint);
}
}
return vec4 (Ambient, 1.0) * occFrontMaterial_Ambient()
+ vec4 (Diffuse, 1.0) * occFrontMaterial_Diffuse()
+ vec4 (Specular, 1.0) * occFrontMaterial_Specular();
}
//! Entry point to the Fragment Shader
void main()
{
gl_FragColor = computeLighting (normalize (Normal),
normalize (View),
Position);
}
~~~~~

View File

@@ -1,283 +0,0 @@
Contribution Workflow {#dev_guides__contribution_workflow}
====================================
@tableofcontents
@section occt_contribution_workflow_1 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
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.
@subsection occt_contribution_workflow_1_2 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 | 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 |
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
@subsection occt_contribution_workflow_2_1 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"
@subsection occt_contribution_workflow_2_2 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:
* **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.
The newly registered issue gets status **NEW** and is assigned to the developer responsible for the OCCT component indicated in the Category field (Maintainer).
@subsection occt_contribution_workflow_2_3 Assigning the issue
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 recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution.
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.
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.
* If Reviewer detects some problems, he can either:
* Fix these issues and provide new solution, reassigning the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**.
Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developers forum if necessary).
* Reassign the issue back to the **Developer**, providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided.
* If Reviewer does not detect any problems, he changes status to **REVIEWED**.
@subsection occt_contribution_workflow_2_6 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.
@subsection occt_contribution_workflow_2_7 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:
@image html OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches"
@image latex OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches"
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.
@subsection occt_contribution_workflow_2_8 Closing a bug
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_2_9 Reopening a bug
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.
@section occt_contribution_workflow_3 Appendix
@subsection occt_contribution_workflow_3_1 Issue attributes
@subsubsection occt_contribution_workflow_3_1_1 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 |
@subsubsection occt_contribution_workflow_3_1_2 Statuses of issues
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. |
| 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. |
| 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. |
@subsubsection occt_contribution_workflow_3_1_3 Resolutions
**Resolution** is set when the bug is resolved. "Reopen" resolution is added automatically when the bug is reopened.
| Resolution | Description |
|:--------------------- | :--------------------------------------------------------------------------- |
| Open | The issue is being processed. |
| Fixed | The issue has been successfully fixed. |
| Reopened | The bug has been reopened because of insufficient fix or regression. |
| | Unable to reproduceThe 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. |
| Duplicate | The bug for the same issue already exists in the tracker. |
| Not a bug | It is a normal behavior in accordance with the specification of the product |
| No change required | The issue didnt require any change of the product, such as a question issue |
| Suspended | This resolution is set for Acknowledged status only. It means that the issue is waiting for fix until a special administrative decision is taken (e.g. a budget is not yet set in accordance with the contract) |
| Documentation updated | The issue was a normal behavior of the product, but the actions of the user were wrong. The specification and the user manual have been updated to reflect this issue. |
| Wont fix | An administrative/contractual decision has been taken to not fix the bug |
@subsection occt_contribution_workflow_3_2 Update and evolution of documentation
The documentation on Open CASCADE Technology currently exists in three forms:
* OCCT Technical Documentation generated automatically with Doxygen tool on the basis of comments in CDL or HXX files.
* Users Reference Documentation on OCCT packages and Products supplied in the form of PDF Users guides
* OCCT Release Documentation supplied in the form of Release Notes with each release.
It is strictly required to properly report the improvements and changes introduced in OCCT in all three forms of Documentation.
@subsubsection occt_contribution_workflow_3_2_1 Maintenance of CDL files
Every developer providing a contribution to the source code of OCC
should make a relevant change in the corresponding header file, including CDL.
Making the appropriate comments is mandatory in the following cases:
* Development of a new package / class / method / enumeration;
* Modification of an existing package / class / method / enumeration that changes its behavior;
* Modification / new development impacts at other packages / classes / methods / enumerations, the documentation which of should be modified correspondingly.
The only case when the comments may be not required is introducing
a modification that does not change the existing behavior in any noticeable way
or brings the behavior in accordance with the existing description.
CDL description must be in good English, containing as much relevant
information and as clear as possible. If the developer is unable to properly formulate
his ideas in English or suspects that his description can be misunderstood,
he should address to the Documentation Engineer for language assistance.
Such action is completely subject to the discretion of the developer; however,
the Documentation Engineer can require that the developer should provide a relevant
technical documentation and reopen a bug until all documentation satisfies the requirements above.
@subsubsection occt_contribution_workflow_3_2_2 Maintenance of the Users Reference Documentation
The Users Reference Documentation is distributed among a number of Users Guides,
each describing a certain module of OCCT.
The User's Guides do not cover the entire functionality of OCCT;
however, they describe most widely used and important packages.
In most aspects the User's Guides present the information that is contained in CDL descriptions for methods, classes, etc., only from a different point of view. Thus, it is required that any developer who implements a new or modifies an existing package / class / method / enumeration and adds a description of new development or changes in the corresponding CDL file should also check if this class package / class / method / enumeration or the package / class, to which the added class / method belongs is already described in the documentation and update the Users Reference Documentation correspondingly.
3.2.3. Preparation of the Release Documentation
Before changing the bug Status to RESOLVED, the developer should provide a description of the implemented work using the "Additional information and documentation updates" field of Mantis bugtracker.
This description is used for the Release Documentation and has the following purposes:
* to inform the OCCT users about the main features and improvements implemented in the platform in the release;
* to give a complete and useable list of changes introduced into the OCCT since the latest version.
The changes should be described from the users viewpoint so that the text
could be comprehensible even for beginners having a very vague idea about OCCT.
If the developer is unable to properly formulate his ideas in English or suspects
that his description can be misunderstood, he should address to the Documentation Engineer
for language assistance. Such action is completely subject to the discretion of the developer;
however, the Documentation Engineer can require that the developer
should provide a relevant technical documentation and reopen a bug
until all documentation satisfies the requirements.
**Note**, that it is required to single out the changes in the OCCT behavior as compared to the previous versions and especially the changes to be considered when porting from the previous version of OCCT.
For example:
* If global macros XXX() was used in the code of your application, revise it for direct use of the argument stream object.
* You might need to revise the code related to text display in 3d viewer to take into account new approach of using system fonts via XXX library.
The **Documentation Engineer** is responsible for preparation of the version Release Notes
and update of the Users Guides. If the **Documentation Engineer** considers that the description currently provided by the **Developer** is somehow inadequate or unsatisfactory he can demand the **Developer** to rewrite the documentation with the **Documentation Engineers** assistance.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 89 KiB

View File

@@ -1,17 +0,0 @@
Developer Guides {#dev_guides}
================
The following documents provide information on OCCT building, development and testing:
* @subpage dev_guides__building "Building OCCT from sources"
* @subpage dev_guides__documentation "Documentation system"
* @subpage dev_guides__coding_rules "Coding Rules"
* @subpage dev_guides__contribution_workflow "Contribution Workflow"
* @subpage dev_guides__git_guide "Guide to installing and using Git for OCCT development"
* @subpage dev_guides__tests "Automatic Testing system"
Two other documents provide details on obsolete technologies used by OCCT,
to be removed in future releases:
* @subpage dev_guides__wok "Workshop Organization Kit (WOK)"
* @subpage dev_guides__cdl "Component Definition Language (CDL)"

View File

@@ -1,522 +0,0 @@
Documentation System {#dev_guides__documentation}
======================
@tableofcontents
@section OCCT_DM_SECTION_1 Introduction
This document provides practical guidenes for generation and editing of OCCT user documentation.
@section OCCT_DM_SECTION_2 Prerequisites
<b>Tcl/Tk</b>
Version 8.5 or 8.6: http://www.tcl.tk/software/tcltk/download.html
<b>Doxygen</b>
Version 1.8.4 or above: http://www.stack.nl/~dimitri/doxygen/download.html
<b>MathJax</b> (used for rendering math formulas in browser).
See \ref OCCT_DM_SECTION_A_9 paragraph for more detailed description.
The latest version: http://www.mathjax.org/download/
<b>MiKTeX</b> or equivalent tool (used for PDF document creation)
Latest version: http://miktex.org/download
**Note**: to generate pdf documentation with MiKTeX you should execute gendoc.bat within MiKTeX environment
(run gendoc.bat in MiKTeX command promt or update PATH for MiKTeX bin folder). Also in process of pdf generation
MiKTeX can request you to download missing packages if MiKTeX was installed with option below:
@image html /dev_guides/documentation/images/documentation_image002.png
@image latex /dev_guides/documentation/images/documentation_image002.png
If this option is set to "Yes", MiKTeX will download missing packages automatically.
@section OCCT_DM_SECTION_2_1 Documentation Generation
Run gendoc.bat from OCCT directory to generate all articles are defined in FILES.txt:
gendoc.bat options:
* -html : To generate HTML files (cannot be used with -pdf);
* -pdf : To generate PDF files (cannot be used with -html);
* -m=\<modules_list\> : Specifies list of articles to generate. If it is not specified, all files, mentioned in FILES.txt are processed;
* -l=\<document_name\> : Specifies the article caption for a single document;
* -h : Prints help message;
* -v : Specifies the Verbose mode (info on all script actions is shown).
If you run the command without arguments (like example above) it will generate HTML documentation
for all articles are defined into FILES.txt.
**Note**: the generation process generates PDF files for each article,
but in html case it generates common Html page with references to the ones.
For generation of specific article you need:
* have it's name with relative path (from \%OCCDIR\%/dox/ to the file) contained in FILES.txt
(is located into \%OCCDIR\%/dox/ directory).
@verbatim
devs_guid/documentation/documentation.md
@endverbatim
where documentation .md is name of article and devs_guid/documentation/ is relative path of it
* use this name with -m option in the generation process:
@verbatim
% gendoc.bat -html -m=devs_guid/documentation/documentation.md
@endverbatim
Multiple files are separated with comma:
@verbatim
% gendoc.bat -html -m=MD_FILE_1,MD_FILE_2
@endverbatim
To sepcify a article name with -l option, use quotes to prevent incorrect interpretation of whitespaces:
@verbatim
% gendoc.bat -pdf -m=MD_FILE_1 -l="Label of MD_FILE_1 document"
@endverbatim
@section OCCT_DM_SECTION_3 Documentation Conventions
This section contains information about conventions in the field of OCCT documentation file format,
structure of documentation directories, etc.
@subsection OCCT_DM_SECTION_3_1 File Format
The format used for documentation is MarkDown with Doxygen extensions.
The MarkDown files have a "*.md" extension and are based on rules desribed in
\ref OCCT_DM_SECTION_A section.
@subsection OCCT_DM_SECTION_3_2 Directory Structure
@image html /dev_guides/documentation/images/documentation_image001.png
@image latex /dev_guides/documentation/images/documentation_image001.png
Every separate article has own folder if images are used in it. These images
are stored into "images" subfolder.
If you want to use the same image for several articles, you can place the one into "dox/resources" folder.
**Note**: Every article can use any image that is used by others articles. To avoid incorrect image
displaying, use relative path to the image (starting from dox folder). For instance
@verbatim
@image html /dev_guides/snv/images/snv_image001.svg
@endverbatim
Result of generation of the documentation is:
%OCCT_DIR% / doc - a folder for generated articles;
* html/ - a directory for generated HTML pages;
* pdf/ - a directory for generated PDF files.
@section OCCT_DM_SECTION_4 Adding a New Article
- Place a new article into folder that is chosen taking into account the place of the article
at the hierarchy of the documentation. For instance the article about "using SVN working with OCCT
source code" (svn.md - the file of the article) might be placed into /dox/dev_guides/ . If the article has images then you may create
the own folder of the article and subfolder in it for images. For instance
*/dox/dev_guides/svn/ - for svn.md file
*/dox/dev_guides/svn/images/ - for images
- Update dox/FILES.txt to add relative path to svn.md. For instance
@verbatim
dev_guides/snv/svn.md
@endverbatim
**Note**: the place of the relative path to an article is connected with the place
into treeview of html version.
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.
@section OCCT_DOC_SECTION_5 Additional Resources
More information about OCCT can be found at http://www.opencascade.org
The information on formula syntax can be found at:
http://en.wikipedia.org/wiki/Help:Displaying_a_formula
More information on MarkDown and Doxygen syntax can be found at:
http://www.stack.nl/~dimitri/doxygen/manual
@section OCCT_DM_SECTION_A Appendix 1: Document Syntax
Each OCCT document file in *.md format has a simple structure.
It can contain:
| Content type | Obligation |
| :---------------- | :-------------------: |
| Header | M |
| Footer | M |
| Plain text | O |
| List | O |
| Table | O |
| Code | O |
| Formula | O |
| Image | O |
| Page numbers | M (auto generation) |
| Table of contents | M (auto generation) |
The legend:
* M is for Mandatory
* O is for Optional
@subsection OCCT_DM_SECTION_A_1 Text Caption (a header)
headings of different levels can be specified with the following code:
@verbatim
Header 1 {#header1}
=======
@endverbatim
to get
Header 1
=========
and with the following code:
@verbatim
Header 2 {#header2}
--------
@endverbatim
to get
Header 2
---------
Where a word in curly braces is a MarkDown-style reference, which can be used in table of contents.
If you would like to have the table of contents, it is recommended to use \@section,
\@subsection and \@subsubsection pages instead of MarkDown headers as follows:
@verbatim
@section Section_Name Section Header
@subsection SubSection_Name SubSection Header
@subsubsection SubSubSection_Name SubSubSection Header
@endverbatim
@subsection OCCT_DM_SECTION_A_2 Plain Text
Plain text is a text in a notepad-like format. To insert special symbols,
like \< , \> or \\, prepend them with \\ character: \\\<, \\\>, \\\\
To emphasize some words, write one pair of asterisks ( * ) or underscores ( _ ) across the word
to make it *italic* and two pairs of these symbols to make a word **Bold**.
@subsection OCCT_DM_SECTION_A_3 Lists
To create a bulleted list, start each line with a hyphen or an asterisk,
followed by a space. List items can be nested. This code:
@verbatim
* Bullet 1
* Bullet 2
- Bullet 2a
- Bullet 2b
* Bullet 3
@endverbatim
produces this list:
* Bullet 1
* Bullet 2
* Bullet 2a
* Bullet 2b
* Bullet 3
To create a numbered list, start each line with number and a period,
then a space. Numbered lists can also be nested. Thus this code
@verbatim
1. List item 1
1. Sub-item 1
2. Sub-item 2
2. List item 2
3. List item 3
@endverbatim
produces this list:
1. List item 1
1. Sub-item 1
2. Sub-item 2
2. List item 2
3. List item 3
Each list item can contain several paragraphs of text; these paragraphs must
have the same indentation as text after bullet or number in the numbered list
item (otherwise numbering will be broken).
Code blocks can be inserted as paragraphs with additional indentation
(4 spaces more). Note that fenced code blocks do not work within numbered lists
and their use may cause numeration to be reset.
Example of complex nested list:
@verbatim
1. ListItem_1
Additional paragraph
code fragment
One more paragraph
1. Sub-item 1
code fragment for sub-item 1
2. Sub-item 2
Paragraph for sub-item 2
Yet one more paragraph for list item 1
2. ListItem_2
@endverbatim
1. List item 1
Additional paragraph
code fragment
One more paragraph
1. Sub-item 1
code fragment for sub-item 1
2. Sub-item 2
Paragraph for sub-item 2
Yet one more paragraph for list item 1
2. List item 2
Note that numbers of paragraphs are regenerated so they do not necessarily
follow numbering of source items.
@subsection OCCT_DM_SECTION_A_4 Tables
A table consists of a header line, a separator line, and at least one row line.
Table columns are separated by the pipe (|) character. The following example:
@verbatim
First Header | Second Header
------------- | -------------
Content Cell | Content Cell
Content Cell | Content Cell
@endverbatim
will produce the following table:
First Header | Second Header
------------ | -------------
Content Cell | Content Cell
Content Cell | Content Cell
Column alignment can be controlled via one or two colons at the header separator line:
@verbatim
| Right | Center | Left |
| ----: | :----: | :---- |
| 10 | 10 | 10 |
| 1000 | 1000 | 1000 |
@endverbatim
which will looks as follows:
| Right | Center | Left |
| ----: | :----: | :---- |
| 10 | 10 | 10 |
| 1000 | 1000 | 1000 |
Note that each table raw should be contained in one line of text; complex
tables can be created using HTML tags.
@subsection OCCT_DM_SECTION_A_5 Code Blocks
It is recommended to indent a code lines with 4 spaces.
A fenced code block does not require indentation, and is defined by a pair of "fence lines".
Such line consists of 3 or more tilde (~) characters on a line.
The end of the block should have the same number of tildes. Here is an example:
~~~~~~~~~~~~~~~~~~~~~~~
a one-line code block
~~~~~~~~~~~~~~~~~~~~~~~
By default the output is the same as for a normal code block.
To highlight the code, the developer has to indicate the typical file extension,
which corresponds to the programming language, after the opening fence.
For highlighting according to the C++ language, for instance, write the following code (the curly braces and dot are optional):
@verbatim
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
int func(int a,int b) { return a*b; }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@endverbatim
which will produce:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
int func(int a,int b) { return a*b; }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Verbatim content can be written by using framing \@verbatim \@endverbatim . For instance
verbatim text
@subsection OCCT_DM_SECTION_A_6 References
To insert a reference to a website, it is proposed to write a URL. For example: http://en.wikipedia.org
To insert a reference to another part of the same document, the developer can write:
@verbatim
@htmlonly
<a href="#OCCT_DOC_SECTION_5">Doxygen Configuration file</a>
@endhtmlonly
@endverbatim
to get a link to paragraph : @htmlonly <a href="#OCCT_DOC_SECTION_5">Doxygen configuration</a> @endhtmlonly
@subsection OCCT_DM_SECTION_A_7 Images
To insert image into document the developer can write the following code(in Doxygen-style):
For HTML document:
@verbatim
@image html /relative/path/to/image/image001.png "Image caption"
@endverbatim
For latex document:
@verbatim
@image latex /relative/path/to/image/image001.png "Image caption"
@endverbatim
*Note*: When markdown document is used to generate html document the latex insertion is ignored (and vice versa)
due to this fact you can use image insertions in the pair, like example below:
@verbatim
@image html /relative/path/to/image/image001.png "Image caption"
@image latex /relative/path/to/image/image001.png "Image caption"
@endverbatim
The code below tells Doxygen to insert a picture right in the place this code was written:
@verbatim
@image html /resources/occ_logo.png "OCCT logo"
@image latex /resources/occ_logo.png "OCCT logo"
@endverbatim
@image html /resources/occ_logo.png "OCCT logo"
@image latex /resources/occ_logo.png "OCCT logo"
@subsection OCCT_DM_SECTION_A_8 Table Of Contents
To get the table of contents at the beginning of the document, write \@tableofcontents tag.
But it is not needed now because TreeView option for HTML is used.
The TOC in the PDF document will be generated automatically.
@subsection OCCT_DM_SECTION_A_9 Formulas
Formulas within documents will be generated using MathJax tool.
A developer has to specify these parameters in Doxyfile to enable support of MathJax in Doxygen:
USE_MATHJAX = YES
MATHJAX_FORMAT = HTML-CSS
MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
To use MathJax tool with the HTML page, it's \<head\> block has to contain
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.html}
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
tex2jax: {inlineMath: [["$","$"],["\\(","\\)"]]},
displayAlign: "left"
});
</script>
<script type="text/javascript"
src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First script configures MathJax to understand separator types and to left allign formulas.
The second script inserts reference to MathJax tool.
This tool will always be used when the HTML output will be shown.
Equations can be written by several ways:
1.Unnumbered displayed formulas that are centered on a separate line.
These formulas should be put between \@f\[ and \@f\] tags. An example:
@verbatim
@f[
|I_2|=\left| \int_{0}^T \psi(t)
\left\{
u(a,t)-
\int_{\gamma(t)}^a
\frac{d\theta}{k(\theta,t)}
\int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
\right\} dt
\right|
@f]
@endverbatim
gives the following result:
@f$
|I_2|=\left| \int_{0}^T \psi(t)
\left\{
u(a,t)-
\int_{\gamma(t)}^a
\frac{d\theta}{k(\theta,t)}
\int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
\right\} dt
\right|
@f$
2.Formulas can also be put between @verbatim \begin{align} @endverbatim and @verbatim \end{align} @endverbatim tags. An example:
@verbatim
\begin{align}
\dot{x} & = \sigma(y-x) \\
\dot{y} & = \rho x - y - xz \\
\dot{z} & = -\beta z + xy
\end{align}
@endverbatim
gives the following result:
@latexonly
\begin{align}
\dot{x} & = \sigma(y-x) \\
\dot{y} & = \rho x - y - xz \\
\dot{z} & = -\beta z + xy
\end{align}
@endlatexonly
@htmlonly
\begin{align}
\dot{x} & = \sigma(y-x) \\
\dot{y} & = \rho x - y - xz \\
\dot{z} & = -\beta z + xy
\end{align}
@endhtmlonly
3.Inline formulas can be specified using this syntax:
@verbatim
@f$ \sqrt{3x-1}+(1+x)^2 @f$
@endverbatim
that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.4 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 37 KiB

View File

@@ -1,550 +0,0 @@
Guide to installing and using Git for OCCT development {#dev_guides__git_guide}
=================================
@tableofcontents
@section occt_gitguide_1 Overview
@subsection occt_gitguide_1_1 Purpose
The purpose of this document is to provide a practical introduction to Git
to OCCT developers who are not familiar with this tool
and to facilitate the use of the official OCCT Git repository for code contribution to OCCT.
Reading this document does not exempt from the need to learn Git concepts and tools.
Please consult a book or manual describing Git to get acquainted with this tool.
Many good books on Git can be found at http://git-scm.com/documentation
For the experienced Git users it can be enough to read sections 1 and 3
of this document to start working with the repository.
Please make sure to get familiar with the Contribution Workflow document
that describes how Git is used for processing contributions to OCCT.
This and related documents are available at the Resources page
of the OCCT development portal at http://dev.opencascade.org/index.php?q=home/resources.
@subsection occt_gitguide_1_2 Git URL
URL of the official OCCT source code Git repository (accessed by SSH protocol) is:
gitolite@git.dev.opencascade.org:occt
or
ssh://gitolite@dev.opencascade.org/occt.git
@subsection occt_gitguide_1_3 Content
The official repository contains:
* The current certified version of OCCT: the "master" branch. This branch is updated by the Bugmaster only. Official OCCT releases are marked by tags.
* Topic branches created by contributors to submit changes for review / testing or for collaborative development. The topic branches should be named by the pattern "CR12345" where 12345 is the ID of the relevant issue registered in Mantis (without leading zeroes), and "CR" stands for "Change Request". The name can have an additional postfix used if more than one branch was created for the same issue.
* Occasionally topic branches with non-standard names can be created by the Bugmaster for special needs.
@subsection occt_gitguide_1_4 Short rules of use
The name specified in the user.name field in Git configuration should correspond
to your login name on the OCCT development portal.
This is important to clearly identify the authorship of commits.
(The full real name can be used as well; in this case add the login username in parentheses.)
By default, contributors are allowed to push branches only with the names starting with CR
(followed by the relevant Mantis issue ID).
Possibility to work with other branches can be enabled by the Bugmaster on request.
The branch is created by the developer in his local repository when the development of a contribution starts.
The branch for new developments is to be created from the current master.
The branch for integration of patches or developments based on an obsolete version
is created from a relevant tag or commit. The branch should be pushed to the official repo
only when sharing with other people (for collaborative work or review / testing) is needed.
Rebasing the local branch to the current master is encouraged before the first submission
to the official repository. If rebasing was needed after the branch is pushed to the official repo,
the rebased branch should have a different name (use suffix).
Integration of contributions that have passed certification testing is made exclusively by the Bugmaster.
Normally this is made by rebasing the contribution branch on the current master
and squashing it into a single commit. This is made to have the master branch history plain and clean,
following the general rule “one issue one commit”.
The description of the commit integrated to the master branch is taken from the Mantis issue
(ID, 'Summary', followed by the information from 'Documentation' field if present).
In special cases when it is important to save the commits history in the branch
(e.g. in case of a long-term development integration) it can be integrated by merge (no fast-forward).
The authorship of the contribution is respected by preserving the Author field of the commit when integrating.
Branches are removed from the official repository when integrated to the master.
The Bugmaster can also remove branches which have no commits during one-month period.
The Bugmaster may ask the developer (normally the one who produced the contribution)
to rebase a branch on the current master, in the case if merge conflicts appear during integration.
@subsection occt_gitguide_1_5 Version of Git
The repository is tested to work with Git 1.7.6 to 1.7.9.
Please do not use versions below 1.7.1 as they are known to cause troubles.
@section occt_gitguide_2 Installing Tools for Work with Git
@subsection occt_gitguide_2_1 Windows platform
Installation of Git for Windows (provided by MSysGit project) is required.
In addition, it is recommended to install TortoiseGit to work with Git on Windows.
If you do not install TortoiseGit or any other GUI tool,
you can use GitGui and Gitk GUI tools delivered with Git and available on all platforms.
@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.
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
* 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
in subdirectories *share/git-gui/lib/msgs* and *share/gitk/lib/msgs* of the Git installation directory.
Before the first commit to the OCCT repository, make sure that your User Name in the Git configuration file (file *.gitconfig* in the $HOME directory) is equal to your username on the OCCT development portal.
@subsubsection occt_gitguide_2_1_2 Installation and configuration of TortoiseGit
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.
TortoiseGit integrates to 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
Note that if you have installed MSysGit or have Git installed in non-default path,
on the first time you use TortoiseGit you may get the message demanding to define path to Git.
In such case, click on **Set MSysGit path** button and add the path to git.exe
and path to MigGW libraries in the Settings dialog.
* After the installation select Start -> Programs -> TortoiseGit Settings to configure TortoiseGit.
Select Git->Config to add your user name and Email address to the local .gitconfig file
@image html OCCT_GitGuide_V2_image006.png
@image latex OCCT_GitGuide_V2_image006.png
@subsection occt_gitguide_2_2 Linux platform
We assume that Linux users have Git already installed and available in the PATH.
Make sure to configure Git so that the user name is equal to your username
on the OCCT development portal, and set SafeCrLf option to true:
~~~~~
> git config --global user.name "Your User Name"
> git config --global user.email your@mail.address
> git config --global your@mail.address
~~~~~
@section occt_gitguide_3 Getting access to the repository
@subsection occt_gitguide_3_1 Prerequisites
Access to the repository is granted to the users who have signed the Contributor License Agreement.
The repository is accessed by SSH protocol, thus you need to register your public SSH key
on the development portal to get access to the repository.
SSH keys are used for secure authentication of the user when accessing the Git server.
Private key is the one stored on the user workstation (optionally encrypted).
Open (or public) key is stored in the user account page on the web site.
When Git client accesses the remote repository through SSH,
it uses this key pair to identify the user and acquire relevant access rights.
Normally when you have Git installed, you should have also SSH client available.
On Unix/Linux it is installed by default in the system.
On Windows it is typical to have several SSH clients installed;
in particular they are included with Cygwin, Git, TortoiseGit.
It is highly recommended to use the tools that come
with the chosen Git client for generation of SSH keys.
Using incompatible tools (e.g. ssh-keygen.exe from Cygwin for code generation,
and TortoiseGit GUI with a default Putty client for connection to server)
may lead to authentication problems.
@subsection occt_gitguide_3_2 How to generate a key
@subsubsection occt_gitguide_3_2_1 Generating key with Putty
Use this option if you have installed TortoiseGit (or other GUI Git client on Windows)
and have chosen “TortoisePLink” (or other Putty client) as SSH client during installation.
To generate the key with this client, run Puttygen (e.g. from Start menu -> TortoiseGit -> Puttygen),
then click Generate and move mouse cursor over the blank area until the key is generated.
@image html OCCT_GitGuide_V2_image007.png "Putty key generator"
@image latex OCCT_GitGuide_V2_image007.png "Putty key generator"
After the key is generated, you will see GUI controls to define the public key comment
and / or specify the password for the private key protection.
When done, save both the public and the private key to the files of your choice
(make sure to store your private key in a secure place!).
Copy the public key as shown by Puttygen to the clipboard to add it in your account.
Do not copy the Putty public key file content -- it is formatted in a way not suitable for the web site.
@subsubsection occt_gitguide_3_2_2 Generating key with command-line tools
Use this option if you work on Linux or if you have chosen “OpenSSH” as SSH client
during installation of TortoiseGit (or other Windows tool).
Make sure that you have *ssh* and *ssh-keygen* commands in the path.
On Windows, you might need to start 'Git Bash' command prompt window provided by Git for Windows.
Use the following command to generate SSH keys:
~~~~~
> ssh-keygen -t rsa -C "your@mail.address"
~~~~~
The last argument is an optional comment, which can be included with the public key and used to distinguish between different keys (if you have many). The common practice is to put here your mail address or workstation name.
The command will ask you where to store the keys. It is recommended to accept the default path *$HOME/.ssh/id_rsa*. Just press Enter for that. You will be warned if a key is already present in the specified file; you can either overwrite it by the new one, or stop generation and use the old key.
If you want to be on the safe side, enter password to encrypt the private key. You will be asked to enter this password each time you use that key (e.g. access a remote Git repository), unless you use the tool that caches the key (like TortoiseGit). If you do not want to bother, enter an empty string.
On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/):
* *id_rsa* - private key
* id_rsa.pub - public key
The content of the public key file (one text line) is the key to be added to the user account on the site (see below).
@subsubsection occt_gitguide_3_2_3 Generating key with Git GUI
GitGUI (standard GUI interface included with Git) provides the option
to either generate the SSH key (if not present yet) or show the existing one.
Click Help/Show SSH key and copy the public key content for adding to the user account page (see below).
@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
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.
It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal.
Please note that some time (5-10 min) is needed for the system
to update the configuration after the new key is added.
After that time, you can try accessing Git.
@section occt_gitguide_4 WORK WITH REPOSITORY: DEVELOPER OPERATIONS
@subsection occt_gitguide_4_1 General workflow
To start working with OCCT source repository, you need to create its clone in your local system.
This cloned repository will manage your working copy of the sources
and provide you the means to exchange code between your clone and the origin.
In most cases it is sufficient to have one clone of the repository;
your working copy will be updated automatically by Git when you switch branches.
The typical development cycle for an issue is as follows:
* Create a new branch for your development, basing on the selected version of the sources
(usually the current master) and switch your working copy to it
* Develop and test your change. Note that for the first time, and after any changes
made in CDL files you will have to re-generate build scripts or Visual Studio projects using WOK.
* Do as many commits in your branch as you feel convenient;
the general recommendation is to commit every stable state (even incomplete), to record the history of your development.
* Push your branch to the repository when your development is complete or when you need to share it with other people (e.g. for review)
* Before the first push, rebase your local branch on the latest master;
consider collapsing the history in one commit unless you think the history of your commits is interesting for others.
Make sure to provide a good commit message.
* Do not amend the commits that have been already pushed in the remote repository,
If you need to rebase your branch, commit the rebased branch under a different name, and remove the old branch.
You can switch to another branch at any moment
(unless you have some uncommitted changes in the working copy)
and return back to the branch when necessary (e.g. to take into account review remarks).
Note that only the sources that are different between the switched branches will be modified,
thus required recompilation should be reasonably small in most cases.
@subsection occt_gitguide_4_2 Cloning official repository
Clone the official OCCT repository in one of following ways:
* From command line by command:
~~~~~
> git clone gitolite@git.dev.opencascade.org:occt <path>
~~~~~
where <i><path></i> is the path to the new folder which will be created for the repository.
* In TortoiseGit: create a new folder, open it and right-click in the Explorer window, then choose **Git Clone** in the context menu:
@image html OCCT_GitGuide_V2_image009.png
@image latex OCCT_GitGuide_V2_image009.png
If you have chosen Putty as SSH client during TortoiseGit installation, check the **Load Putty Key** option and specify the location of the private key file saved by PuttyGen (see 3.2.1). This shall be done for the first time only.
Note that on the first connection to the repository server you may be requested to enter a password for your private SSH key; further you can get a message that the authenticity of the host cannot be established and will be asked if you want to continue connecting or not. Choose **Yes** to continue. The hosts key will be stored in <i>$HOME/.ssh/known_hosts</i> file.
@subsection occt_gitguide_4_3 Branch creation
You need to create a branch when you are going to start development of a new change,
apply a patch, etc. It is recommended to fetch updates from the remote repository
before this operation, to make sure you work with the up-to-date version.
Create a branch from the current master branch unless you need to base your development on a particular version or revision.
In the console:
~~~~~
> git checkout -b CR12345 origin/master
~~~~~
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
@image latex OCCT_GitGuide_V2_image012.png
Check option **Switch to new branch** if you are going to start working with the newly created branch immediately.
@subsection occt_gitguide_4_4 Branch switching
If you need to switch to another branch, use Git command checkout for that.
In the console:
~~~~~
> git checkout CR12345
~~~~~
In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Switch/Checkout**.
@image html OCCT_GitGuide_V2_image013.png
@image latex OCCT_GitGuide_V2_image013.png
Note that in order to work with the branch locally you need to set option
**Create new branch** when you checkout the branch from the remote repository for the first time.
Option **Track** stores association between the local branch and the original branch in a remote repository.
@subsection occt_gitguide_4_5 Committing branch changes
Commit your changes locally as soon as a stable status of the work is reached.
Make sure to review carefully the committed changes beforehand to avoid unintentional commit of a wrong code.
* In the console:
~~~~~
> git diff
> git commit -a -m "Write meaningful commit message here"
~~~~~
Option a tells the command to automatically include (stage) files
that have been modified or deleted, but it will omit the new files that might have been added by you.
To commit such new files, you must add (stage) them before commit command.
To find new unstaged files and them to commit, use commands:
~~~~~
> git status -s
?? file1.hxx
?? file2.cxx
> git add file1.hxx file2.cxx
~~~~~
* In TortoiseGit: right-click in the explorer window and select in the context menu <b>Git Commit -> CR…</b>:
@image html OCCT_GitGuide_V2_image014.png
@image latex OCCT_GitGuide_V2_image014.png
Unstaged files will be shown if you check the option Show Unversioned Files.
Double-clock on each modified file to see the changes to be committed (as a difference vs. the base version).
@subsection occt_gitguide_4_6 Pushing branch to the remote repository
When the code developed in your local branch is ready for review,
or you need to share it with others, push your local changes to the remote repository.
* In the console:
~~~~~
> git push "origin" CR12345:CR12345
~~~~~
* In TortoiseGit: right-click in the explorer window and select in the context menu, TortoiseGit -> **Push**
@image html OCCT_GitGuide_V2_image015.png
@image latex OCCT_GitGuide_V2_image015.png
Note that Git forbids pushing a branch if the corresponding remote branch already exists and has some changes, which are not in the history of your local branch. This may happen in different situations:
* You have amended the last commit which is already in the remote repository. If you are sure that nobody else uses your branch, push again with **Force** option.
* You have rebased your branch, so that now it is completely different from the branch in the remote repository. In this case, push it under a different name (add a suffix):
@image html OCCT_GitGuide_V2_image016.png
@image latex OCCT_GitGuide_V2_image016.png
Then remove the original remote branch so that other people recognize that it has been replaced by the new one. For that, select TortoiseGit -> **Push** again, select an empty line for your local branch name,
and enter the name of the branch to be removed in **Remote** field:
* The other developer has committed some changes in the remote branch. In this case, **Pull** changes from the remote repository to have them merged with your version, and push your branch after it is successfully merged.
@subsection occt_gitguide_4_7 Synchronizing with remote repository
Maintain your repository synchronized with the remote one and clean unnecessary stuff regularly.
Use Git command *fetch* with option *prune* to get the update of all branches from the remote repository and to clean your local repository from the remote branches that have been deleted.
* In the console:
~~~~~
> git fetch --prune
~~~~~
* In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Fetch**. Check in **Prune** check-box.
@image html OCCT_GitGuide_V2_image018.png
@image latex OCCT_GitGuide_V2_image018.png
If the branch you are working with has been changed in the remote repository, use Git command *pull* to get the remote changes and merge them with your local branch.
This operation is required in particular to update your local master branch when the remote master changes.
* In console:
~~~~~
> git pull
~~~~~
* In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Pull**.
@image html OCCT_GitGuide_V2_image019.png
@image latex OCCT_GitGuide_V2_image019.png
Note that the local branches of your repository are the primary place, where your changes are stored until they get integrated to the official version of OCCT (master branch). The branches submitted to official repository are for collaborative work, review, and integration - that repository should not be used for long-term storage of incomplete changes.
Remove the local branches that you do not need any more. Note that you cannot delete the current branch. It means that you need to switch to another one (e.g. master) if the branch you are going to delete is the current one.
* In the console:
~~~~~
> git branch -d CR12345
~~~~~
* In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Git Show Log**.
@image html OCCT_GitGuide_V2_image020.png
@image latex OCCT_GitGuide_V2_image020.png
Select **All branches** check-box to view all branches.
Right-click on the branch you want to delete and select **Delete** item in the context menu.
Note that many functions described above can be accessed from the Log View, which is a very convenient tool to visualize and manage branches.
@subsection occt_gitguide_4_8 Applying a fix made on older version of OCCT
If you have a fix made on a previous version of OCCT, perform the following sequence of operations to prepare it for testing and integration to the current development version:
* Identify the version of OCCT on which the fix has been made. In most cases, this will be an OCCT release, e.g. OCCT 6.7.0.
* Find a tag or a commit corresponding to this version in the Git history log of the master branch.
* Create a branch basing on this tag or commit. In TortoiseGit history log: right-click on the base commit, then select **Create branch at this version**.
@image html OCCT_GitGuide_V2_image021.png
@image latex OCCT_GitGuide_V2_image021.png
* Check option **Switch to the new branch** to start working within the new branch immediately, or switch to it separately afterwards.
* Put your fix in the working copy, build and check that it works, then commit to the branch.
* Rebase the branch on the current master. In TortoiseGit: right-click on the working directory, choose **TortoiseGit** -> **Rebase**, select *remotes/origin/master* as UpStream revision, and click **Start**:
@image html OCCT_GitGuide_V2_image022.png
@image latex OCCT_GitGuide_V2_image022.png
Note that you can get some conflicts during rebase. To resolve them, double-click on each conflicted file (highlighted by red in the file list) to open visual merge tool. Switch between conflicting fragments by red arrows, and for each one decide if the code of one or both conflicting versions is to be taken.
@subsection occt_gitguide_4_9 Rebasing with history clean-up
At some moments you might need to rebase your branch on the latest version of the master.
We recommend rebasing before the first submission of the branch for review or when the master has diverged substantially from your branch.
Rebasing is a good occasion to clean-up the history of commits in the branch. Consider collapsing (squashing, in terms of Git) the history of your branch into a single commit unless you deem that having separate commits is important for your future work with the branch or its code reviewing. Git also allows changing the order of commits, edit commit contents and messages, etc.
To rebase your branch into a single commit, you need to do the following:
* Switch to your branch (e.g. “CR12345”)
* In TortoiseGit history log, select a branch to rebase on *(remotes/origin/master)* and in the context menu choose **Rebase “CR12345” onto this**.
* In the **Rebase** dialog, check **Squash All**. You can also change the order of commits and define for each commit whether it should be kept (**Pick**), edited, or just skipped.
@image html OCCT_GitGuide_V2_image023.png
@image latex OCCT_GitGuide_V2_image023.png
* Click **Start**.
* The process will stop if a conflict is detected. In that case, find files with status **Conflicted** in the list (marked by red), and double-click on them to resolve the conflict. When all conflicts are resolved, click **Continue**.
@image html OCCT_GitGuide_V2_image024.png
@image latex OCCT_GitGuide_V2_image024.png
* At the end of the process, edit the final commit message (it should start from the issue ID and a description from Mantis in the first line, followed by a summary of actual changes), and click **Commit**.
@image html OCCT_GitGuide_V2_image025.png
@image latex OCCT_GitGuide_V2_image025.png
@section occt_gitguide_5 Work with repository: Reviewer operations
@subsection occt_gitguide_5_1 Review branch changes using GitWeb
The changes made in the branch can be reviewed without direct access to Git, using GitWeb interface:
* Open GitWeb in your web browser: http://git.dev.opencascade.org/gitweb/?p=occt.git
* Locate the branch you want to review among **heads** (click ‘…’ at the bottom of the page to see the full list).
* Click **log** (or **shortlog**) to see the history of the branch.
**Note** that the branch can contain more than one commit, and you need to distinguish commits that belong to that branch (those to be reviewed) from the commits corresponding to the previous state of the master branch. Normally the first commit in the list that starts from the ID of the other issue indicates the branching point; commits above it are the ones to be reviewed.
* Click **commitdiff** on each log entry to review the changes (highlighted with color format).
@subsection occt_gitguide_5_2 Review branch changes with TortoiseGit
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.
* 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.
* To review all changes made in the branch at once, or to compare two arbitrary revisions, select the corresponding commits in the log (e.g. the last commit in the branch and the branching point), ight-click for the context menu, and choose **Compare revisions**.
@image html OCCT_GitGuide_V2_image026.png
@image latex OCCT_GitGuide_V2_image026.png

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.3 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.2 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.2 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 55 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 95 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

View File

@@ -1,593 +0,0 @@
Automated Testing System {#dev_guides__tests}
======================================
@tableofcontents
@section testmanual_1 Introduction
This document provides overview and practical guidelines for work with OCCT automatic testing system.
Reading this section *Introduction* should be sufficient for OCCT developers to use the test system
to control non-regression of the modifications they implement in OCCT. Other sections provide
more in-depth description of the test system, required for modifying the tests and adding new test cases.
@subsection testmanual_1_1 Basic Information
OCCT automatic testing system is organized around DRAW Test Harness @ref 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 scope of the test system,
e.g. for testing applications based on OCCT.
Logically the tests are organized in three levels:
* Group: group of related test grids, usually relating to some part of OCCT functionality (e.g. blend)
* Grid: 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: script implementing individual test (e.g. K4)
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 code from dev.opencascade.org.
@subsection testmanual_1_2 Intended Use of Automatic Tests
Each modification made in OCCT code must be checked for non-regression
by running the whole set of tests. The developer who does the modification
is responsible for running and ensuring non-regression on the tests that are available to him.
Note that many tests are based on data files that are confidential and thus available only at OPEN CASCADE.
Thus official certification testing of the changes before integration to master branch
of official OCCT Git repository (and finally to the official release) is performed by OPEN CASCADE in any case.
Each new non-trivial modification (improvement, bug fix, new feature) in OCCT
should be accompanied by a relevant test case suitable for verifying that modification.
This test case is to be added by developer who provides the modification.
If a modification affects result of some test case(s),
either the modification should be corrected (if it causes regression)
or affected test cases should be updated to account for the modification.
The modifications made in the OCCT code and related test scripts
should be included in the same integration to master branch.
@subsection testmanual_1_3 Quick Start
@subsubsection testmanual_1_3_1 Setup
Before running tests, make sure to define environment variable CSF_TestDataPath
pointing to the directory containing test data files.
(The publicly available data files can be downloaded
from http://dev.opencascade.org separately from OCCT code.)
The recommended way for that is adding a file *DrawInitAppli*
in the directory which is current at the moment of starting DRAWEXE (normally it is $CASROOT).
This file is evaluated automatically at the DRAW start. Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
set env(CSF_TestDataPath) d:/occt/tests_data
return ;# this is to avoid an echo of the last command above in cout
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All tests are run from DRAW command prompt, thus first run draw.tcl or draw.sh to start DRAW.
@subsubsection testmanual_1_3_2 Running Tests
To run all tests, type command *testgrid* followed by path
to the new directory where results will be saved.
It is recommended that this directory should be new or empty;
use option overwrite to allow writing logs in existing non-empty directory.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
Draw[]> testgrid d:/occt/results-2012-02-27
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If empty string is given as log directory name, the name will be generated automatically
using current date and time, prefixed by *results_*. Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
Draw[]> testgrid {}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For running only some group or a grid of tests,
give additional arguments indicating group and (if needed) grid. Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
Draw[]> testgrid d:/occt/results-2012-02-28 blend simple
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As the tests progress, the result of each test case is reported.
At the end of the log summary of test cases is output,
including list of detected regressions and improvements, if any. Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
Tests summary
CASE 3rdparty export A1: OK
...
CASE pipe standard B1: BAD (known problem)
CASE pipe standard C1: OK
No regressions
Total cases: 208 BAD, 31 SKIPPED, 3 IMPROVEMENT, 1791 OK
Elapsed time: 1 Hours 14 Minutes 33.7384512019 Seconds
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, e.g. because of lack of data file) statuses are reported.
See <a href="#testmanual_3_4">Grids *cases.list* file</a> chapter for details.
The detailed logs of running tests are saved in the specified directory and its sub-directories.
Cumulative HTML report summary.html provides links to reports on each test case.
An additional report TESTS-summary.xml is output in JUnit-style XML format
that can be used for integration with Jenkins or other continuous integration system.
Type *help testgrid* in DRAW prompt to get help on additional options supported by testgrid command.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
Draw[3]> help testgrid
testgrid: Run all tests, or specified group, or one grid
Use: testgrid logdir [group [grid]] [options...]
Allowed options are:
-verbose {0-2}: verbose level, 0 by default, can be set to 1 or 2
-parallel N: run in parallel with up to N processes (default 0)
-refresh N: save summary logs every N seconds (default 60)
-overwrite: force writing logs in existing non-empty directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection testmanual_1_3_3 Running Single Test
To run single test, type command *test* followed by names of group, grid, and test case.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
Draw[1]> test blend simple A1
CASE blend simple A1: OK
Draw[2]>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that normally intermediate output of the script is not shown.
To see intermediate commands and their output, type command *decho on*
before running the test case. (Type decho off to disable echoing when not needed.)
The detailed log of the test can also be obtained after the test execution by command *dlog get*.
@section testmanual_2 Organization of Test Scripts
@subsection testmanual_2_1 General Layout
Standard OCCT tests are located in subdirectory tests of the OCCT root folder ($CASROOT).
Additional test folders can be added to the test system
by defining environment variable CSF_TestScriptsPath.
This should be list of paths separated by semicolons (*;*) on Windows
or colons (*:*) on Linux or Mac. Upon DRAW launch,
path to tests sub-folder of OCCT is added at the end of this variable automatically.
Each test folder is expected to contain:
* Optional file parse.rules defining patterns for interpretation of test results, common for all groups in this folder
* One or several test group directories.
Each group directory contains:
* File grids.list that identifies this test group and defines list of test grids in it.
* Test grids (sub-directories), each containing set of scripts for test cases, and optional files cases.list, parse.rules, begin, and end.
* Optional sub-directory data
* Optional file parse.rules
* Optional files begin and end
By convention, names of test groups, grids, and cases should contain no spaces and be lowercase.
Names begin, end, data, parse.rules, grids.list, cases.list are reserved.
General layout of test scripts is shown on Figure 1.
@image html /dev_guides/tests/images/tests_image001.png
@image latex /dev_guides/tests/images/tests_image001.png
Figure 1. Layout of tests folder
@subsection testmanual_2_2 Test Groups
@subsubsection testmanual_2_2_1 Group Names
Test folder usually contains several directories representing test groups (Group 1, Group N).
Each directory contains test grids for certain OCCT functionality.
The name of directory corresponds to this functionality.
Example:
@verbatim
caf
mesh
offset
@endverbatim
@subsubsection testmanual_2_2_2 Group's *grids.list* File
The test group must contain file *grids.list* file
which defines ordered list of grids in this group in the following format:
~~~~~~~~~~~~~~~~~
001 gridname1
002 gridname2
...
NNN gridnameN
~~~~~~~~~~~~~~~~~
Example:
~~~~~~~~~~~~~~~~~
001 basic
002 advanced
~~~~~~~~~~~~~~~~~
@subsubsection testmanual_2_2_3 Group's *begin* File
The file *begin* is a Tcl script. It is executed before every test in current group.
Usually it loads necessary Draw commands, sets common parameters and defines
additional Tcl functions used in test scripts.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
pload TOPTEST ;# load topological command
set cpulimit 300 ;# set maximum time allowed for script execution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection testmanual_2_2_4 Group's *end* File
The file end is a TCL script. It is executed after every test in current group.
Usually it checks the results of script work, makes a snap-shot
of the viewer and writes *TEST COMPLETED* to the output.
Note: *TEST COMPLETED* string should be presented in output
in order to signal that test is finished without crash.
See <a href="#testmanual_3">Creation And Modification Of Tests</a> chapter for more information.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
if { [isdraw result] } {
checkshape result
} else {
puts *Error: The result shape can not be built*
}
puts *TEST COMPLETED*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection testmanual_2_2_5 Groups *parse.rules* File
The test group may contain *parse.rules* file.
This file defines patterns used for analysis of the test execution log
and deciding the status of the test run.
Each line in the file should specify a status (single word),
followed by a regular expression delimited by slashes (*/*)
that will be matched against lines in the test output log to check if it corresponds to this status.
The regular expressions support subset of the Perl re syntax.
The rest of the line can contain a comment message
which will be added to the test report when this status is detected.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
FAILED /\\b[Ee]xception\\b/ exception
FAILED /\\bError\\b/ error
SKIPPED /Cannot open file for reading/ data file is missing
SKIPPED /Could not read file .*, abandon/ data file is missing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lines starting with a *#* character and blank lines are ignored to allow comments and spacing.
See <a href="#testmanual_2_3_4">Interpretation of test results</a> chapter for details.
If a line matches several rules, the first one applies.
Rules defined in the grid are checked first, then rules in 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.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
FAILED /\\bFaulty\\b/ bad shape
IGNORE /^Error [23]d = [\d.-]+/ debug output of blend command
IGNORE /^Tcl Exception: tolerance ang : [\d.-]+/ blend failure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsection testmanual_2_3 Test Grids
@subsubsection testmanual_2_3_1 Grid Names
Group folder can have several sub-directories (Grid 1… Grid N) defining test grids.
Each test grid directory contains a set of related test cases.
The name of directory should correspond to its contents.
Example:
caf
basic
bugs
presentation
Where **caf** is the name of test group and *basic*, *bugs*, *presentation*, etc are the names of grids.
@subsubsection testmanual_2_3_2 Grids *begin* File
The file *begin* is a TCL script. It is executed before every test in current grid.
Usually it sets variables specific for the current grid.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
set command bopfuse ;# command tested in this grid
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection testmanual_2_3_3 Grids *end* File
The file *end* is a TCL script. It is executed after every test in current grid.
Usually it executes specific sequence of commands common for all tests in the grid.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
vdump $logdir/${casename}.gif ;# makes a snap-shot of AIS viewer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection testmanual_2_3_4 Grids *cases.list* File
The grid directory can contain an optional file cases.list
defining alternative location of the test cases.
This file should contain singe line defining the relative path to collection of test cases.
Example:
../data/simple
This option is used for creation of several grids of tests with the same data files
and operations but performed with differing parameters.
The common scripts are usually located place in common
subdirectory of the test group (data/simple as in example).
If cases.list file exists then grid directory should not contain any test cases.
The specific parameters and pre- and post-processing commands
for the tests execution in this grid should be defined in the begin and end files.
@subsection testmanual_2_4 Test Cases
The test case is TCL script which performs some operations using DRAW commands
and produces meaningful messages that can be used to check the result for being valid.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
pcylinder c1 10 20 ;# create first cylinder
pcylinder c2 5 20 ;# create second cylinder
ttranslate c2 5 0 10 ;# translate second cylinder to x,y,z
bsection result c1 c2 ;# create a section of two cylinders
checksection result ;# will output error message if result is bad
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The test case can have any name (except reserved names begin, end, data, cases.list, parse.rules).
For systematic grids it is usually a capital English letter followed by a number.
Example:
@verbatim
A1
A2
B1
B2
@endverbatim
Such naming facilitates compact representation of results
of tests execution in tabular format within HTML reports.
@subsection testmanual_2_5 Directory *data*
The test group may contain subdirectory data.
Usually it contains data files used in tests (BREP, IGES, STEP, etc.)
and / or test scripts shared by different test grids
(in subdirectories, see <a href="#testmanual_2_3_4">Grids *cases.list* file</a> chapter).
@section testmanual_3 Creation And Modification Of Tests
This section describes how to add new tests and update existing ones.
@subsection testmanual_3_1 Choosing Group, Grid, and Test Case Name
The new tests are usually added in context of processing some bugs.
Such tests in general should be added to group bugs, in the grid
corresponding to the affected OCCT functionality.
New grids can be added as necessary to contain tests on functionality not yet covered by existing test grids.
The test case name in the bugs group should be prefixed by ID
of the corresponding issue in Mantis (without leading zeroes).
It is recommended to add a suffix providing a hint on the situation being tested.
If more than one test is added for a bug, they should be distinguished by suffixes;
either meaningful or just ordinal numbers.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
12345_coaxial
12345_orthogonal_1
12345_orthogonal_2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the case if new test corresponds to functionality for which
specific group of tests exists (e.g. group mesh for BRepMesh issues),
this test can be added (or moved later by OCC team) to this group.
@subsection testmanual_3_2 Adding Data Files Required for a Test
It is advisable that tests scripts should be made self-contained whenever possible,
so as to be usable in environments where data files are not available.
For that simple geometric objects and shapes can be created using DRAW commands in the test script itself.
If test requires some data file, it should be put to subdirectory data of the test grid.
Note that when test is integrated to master branch,
OCC team can move data file to data files repository,
so as to keep OCCT sources repository clean from big data files.
When preparing a test script, try to minimize size of involved data model.
For instance, if problem detected on a big shape can be reproduced on a single face
extracted from that shape, use only this face in the test.
@subsection testmanual_3_3 Implementation of the Script
Test should run commands necessary to perform the operations being tested,
in a clean DRAW session. This includes loading necessary functionality by *pload* command,
if this is not done by *begin* script. The messages produced by commands in standard output
should include identifiable messages on the discovered problems if any.
Usually the script represents a set of commands that a person would run interactively
to perform the operation and see its results, with additional comments to explain what happens.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
# Simple test of fusing box and sphere
box b 10 10 10
sphere s 5
bfuse result b s
checkshape result
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Make sure that file parse.rules in the grid or group directory contains
regular expression to catch possible messages indicating failure of the test.
For instance, for catching errors reported by *checkshape* command
relevant grids define a rule to recognize its report by the word *Faulty*: FAILED /\\bFaulty\\b/ bad shape
For the messages generated in the script the most natural way is to use the word *Error* in the message.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
set expected_length 11
if { [expr $actual_length - $expected_length] > 0.001 } {
puts *Error: The length of the edge should be $expected_length*
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At the end, the test script should output *TEST COMPLETED* string
to mark successful completion of the script.
This is often done by the end script in the grid.
When test script requires data file, use Tcl procedure *locate_data_file*
to get path to the data file, rather than explicit path.
This will allow easy move of the data file from OCCT repository
to the data files repository without a need to update test script.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
stepread [locate_data_file CAROSKI_COUPELLE.step] a *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When test needs to produce some snapshots or other artifacts,
use Tcl variable logdir as location where such files should be put.
Command *testgrid* sets this variable to the subdirectory of the results folder
corresponding to the grid. Command *test* sets it to $CASROOT/tmp unless it is already defined.
Use Tcl variable casename to prefix all the files produced by the test.
This variable is set to the name of the test case.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
xwd $logdir/${casename}.gif
vdisplay result; vfit
vdump $logdir/${casename}-axo.gif
vfront; vfit
vdump $logdir/${casename}-front.gif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
could produce:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
A1.gif
A1-axo.gif
A1-front.gif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsection testmanual_3_4 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.
The OCCT test system recognizes five statuses of the test execution:
* SKIPPED: reported if line matching SKIPPED pattern is found (prior to any FAILED pattern). This indicates that the test cannot be run in the current environment; most typical case is absence of the required data file.
* FAILED: reported if some line matching pattern with status FAILED is found (unless it is masked by preceding IGNORE pattern or a TODO statement, see below), or if message TEST COMPLETED is not found at the end. This indicates that test produces bad or unexpected result, and usually highlights a regression.
* BAD: reported if test script output contains one or several TODO statements and corresponding number of matching lines in the log. This indicates a known problem (see 3.5). The lines matching TODO statements are not checked against other patterns and thus will not cause a FAILED status.
* IMPROVEMENT: reported if test script output contains TODO statement for which no corresponding line is found. This is possible indication of improvement (known problem disappeared).
* OK: If none of the above statuses have been assigned. This means test passed without problems.
Other statuses can be specified in the parse.rules files, these will be classified as FAILED.
Before integration of the change to OCCT repository, all tests should return either OK or BAD status.
The new test created for unsolved problem should return BAD.
The new test created for a fixed problem should return FAILED without the fix, and OK with the fix.
@subsection testmanual_3_5 Marking BAD Cases
If the test produces invalid result at a certain moment then the corresponding bug
should be created in the OCCT issue tracker http://tracker.dev.opencascade.org,
and the problem should be marked as TODO in the test script.
The following statement should be added to such test script:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
puts *TODO BugNumber ListOfPlatforms: RegularExpression*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
where:
* BugNumber is an ID of the bug in the tracker. For example: #12345
* ListOfPlatform is a list of platforms at which the bug is reproduced (e.g. Mandriva2008, Windows or All).
*Note: the platform name is custom for the OCCT test system;*
*it can be consulted as value of environment variable os_type defined in DRAW.*
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
Draw[2]> puts $env(os_type)
windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
* RegularExpression is a regular expression which should be matched against the line indicating the problem in the script output.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
puts *TODO #22622 Mandriva2008: Abort .* an exception was raised*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Parser checks the output of the test and if an output line matches
the RegularExpression then it will be assigned a BAD status instead of FAILED.
For each output line matching to an error expression a separate TODO line
must be added to mark the test as BAD.
If not all the TODO statements are found in the test log,
the test will be considered as possible improvement.
To mark the test as BAD for an incomplete case
(when final TEST COMPLETE message is missing)
the expression *TEST INCOMPLETE* should be used instead of regular expression.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
puts *TODO OCC22817 All: exception.+There are no suitable edges*
puts *TODO OCC22817 All: \\*\\* Exception \\*\\**
puts *TODO OCC22817 All: TEST INCOMPLETE*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@section testmanual_4 Extended Use
@subsection testmanual_4_1 Running Tests on Older Versions of OCCT
Sometimes it might be necessary to run tests on previous versions of OCCT (up to to 6.5.3)
that do not include this test system. This can be done by adding DRAW configuration file DrawAppliInit
in the directory which is current by the moment of DRAW startup,
to load test commands and define necessary environment. Example
(assume that d:/occt contains up-to-date version of OCCT sources
with tests, and test data archive is unpacked to d:/test-data):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
set env(CASROOT) d:/occt
set env(CSF_TestScriptsPath) $env(CASROOT)/tests
source $env(CASROOT)/src/DrawResources/TestCommands.tcl
set env(CSF_TestDataPath) d:/test-data
return
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that on older versions of OCCT the tests are run in compatibility mode
and not all output of the test command can be captured;
this can lead to absence of some error messages (can be reported as improvement).
@subsection testmanual_4_2 Adding Custom Tests
You can extend the test system by adding your own tests.
For that it is necessary to add paths to the directory where these tests are located,
and additional data directory(ies), to the environment variables CSF_TestScriptsPath and CSF_TestDataPath.
The recommended way for doing this is using DRAW configuration file DrawAppliInit
located in the directory which is current by the moment of DRAW startup.
Use Tcl command *_path_separator* to insert platform-dependent separator to the path list.
Example:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
set env(CSF_TestScriptsPath) \
$env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests
set env(CSF_TestDataPath) \
d:/occt/test-data[_path_separator]d:/MyOCCTProject/tests
return ;# this is to avoid an echo of the last command above in cout
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Binary file not shown.

Before

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.9 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

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