View Issue Details

IDProjectCategoryView StatusLast Update
0027344Open CASCADEOCCT:Configurationpublic2016-12-09 16:37
ReportervsrAssigned Tobugmaster  
PrioritynormalSeveritymajor 
Status closedResolutionfixed 
Product Version7.0.0 
Target Version7.1.0Fixed in Version7.1.0 
Summary0027344: Configuration, CMake - bugs with detecting third-party products
DescriptionHere are some issues revealed during testing of OCCT CMake configuration.

1) Information messages printed when configuring OCCT with CMake are confusing.

For example (on Linux):

[sh%] echo $TCLHOME
/dn47/SALOME/PRODUCTS/8x/opt/CentOS.6.3.64/8.0.0/tcltk-8.6.0

[sh%] cmake -D3RDPARTY_GL2PS_DIR:PATH=${GL2PS_ROOT_DIR} -D3RDPARTY_FREETYPE_DIR:PATH=${FREETYPE_ROOT_DIR} -D3RDPARTY_FREEIMAGE_DIR:PATH=${FREEIMAGE_ROOT_DIR} -D3RDPARTY_TBB_DIR:PATH=${TBB_ROOT_DIR} -D3RDPARTY_TK_DIR:PATH=${TCLHOME} -D3RDPARTY_TCL_DIR:PATH=${TCLHOME} -DUSE_FREEIMAGE:BOOL=ON -DUSE_GL2PS:BOOL=ON -DUSE_TBB:BOOL=ON -DUSE_VTK:BOOL=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/dn25/salome/vsr/PRODUCTS/CR27301

-- Info: TCL is used by OCCT
-- Found Tclsh: /dn47/SALOME/PRODUCTS/8x/opt/CentOS.6.3.64/8.0.0/tcltk-8.6.0/bin/tclsh (found version "8.6")
-- Found TCL: /usr/lib64/libtcl.so
-- Found TCLTK: /usr/lib64/libtcl.so
-- Found TK: /usr/lib64/libtk.so
-- Info: TK is used from TCL folder: /dn47/SALOME/PRODUCTS/8x/opt/CentOS.6.3.64/8.0.0/tcltk-8.6.0
-- Info: TK is used by OCCT
-- Info: Freetype is used by OCCT
...

In fact, when looking into the CMakeCache.txt generated by CMake at the end of configuration process, one can see that tcl and tk are found correctly, i.e. related variables are set properly. However, information messages printed to the terminal confuse the user.

Also, it is not clear, what's the difference between "TCL", "TK" and "TCLTK"?

2) There is a bug in configuration file causing CMake error when detecting OCCT in dependent project.

The following line in OpenCASCADEConfig.cmake is incorrect:

set(OpenCASCADE_CONFIG_TARGETS_FILE "${CMAKE_CURRENT_LIST_FILE}/OpenCASCADETargets.cmake")

It has to be corrected:

set(OpenCASCADE_CONFIG_TARGETS_FILE "${CMAKE_CURRENT_LIST_DIR}/OpenCASCADETargets.cmake")

3) Detection of OCCT does not work on Windows when default layout is used.

While on Linux OpenCASCADE is well detected in CONFIG mode, this does not work on Windows. This is because the config files are put to the <prefix>/win32/vc10/lib directory which is not used as one of locations automatically parsed by CMake. This is well written in the CMake documentation (https://cmake.org/cmake/help/v3.5/command/find_package.html):

<prefix>/ (W)
<prefix>/(cmake|CMake)/ (W)
<prefix>/<name>*/ (W)
<prefix>/<name>*/(cmake|CMake)/ (W)
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)

One can see that on Windows CMake only searches config files in:
<prefix>
<prefix>/cmake
<prefix>/CMake
<prefix>/opencascade/cmake
<prefix>/opencascade/CMake

This should be corrected!

4) Definitions are absent in config file.

Absence of CAS_DEFINITIONS variable in the config file can potentially cause compilation or linkage problem in dependent project – if some defines used during OCCT building are somehow exported into the header files. An example of such behavior is BVH_LinearBuilder.lxx where "#ifdef HAVE_TBB" is extensively used.

For instance, in SALOME, due to absence of a way to know what flags have been used when configuring OCCT, some options were explicitly hardcoded in the detection procedure (it came from very early version of SALOME):

# Definitions:
SET(CAS_DEFINITIONS "-DLIN -DLINTEL -DCSFDB")
SET(CAS_DEFINITIONS "${CAS_DEFINITIONS} -DNo_exception")

# No config.h file in the OPEN CASCADE on WINDOWS platform
IF(NOT WIN32)
SET(CAS_DEFINITIONS "${CAS_DEFINITIONS} -DHAVE_CONFIG_H")
ENDIF()

# Test for 64 bit machine:
IF(CMAKE_SIZEOF_VOID_P STREQUAL 8)
  SET(CAS_DEFINITIONS "${CAS_DEFINITIONS} -D_OCC64")
ENDIF()

It seems that some of these defines are not needed anymore, but as we cannot know this exactly so we keep using them. The reason is that OCCT never exported such defines explicitly, so dependent project needed to set these variables themselves to be able to build with OCCT. Such behavior can lead to different problems with linking of OCCT-based solutions, or problems in runtime (as this can, for instance, cause undefined symbols).

The options (in first turn, definitions) which are used during the configuration of OCCT and which can affect the behavior of included OCCT headers, should be exposed to the OCCT config file, via the OpenCASCADE_DEFINITIONS variable.

Currently OCCT config file exports some variables that come from the configuration procedure:

# OpenCASCADE global configuration options.
set (OpenCASCADE_COMPILER "gcc")
set (OpenCASCADE_BUILD_WITH_DEBUG OFF)
set (OpenCASCADE_BUILD_SHARED_LIBS ON)
set (OpenCASCADE_BUILD_TYPE "Release")

# Use of third-party libraries
set (OpenCASCADE_WITH_TCL ON)
set (OpenCASCADE_WITH_FREETYPE ON)
set (OpenCASCADE_WITH_FREEIMAGE ON)
set (OpenCASCADE_WITH_GL2PS ON)
set (OpenCASCADE_WITH_TBB ON)
set (OpenCASCADE_WITH_VTK OFF)

Judging on the source files (*.cmake, CMakeLists.txt) these variables affect on the build procedure of OCCT by specifying additional defines. So, maybe these defines should be exposed to the config file also?

For example, something like below can be done:

# OpenCASCADE global configuration options.
set (OpenCASCADE_COMPILER "gcc")
set (OpenCASCADE_BUILD_WITH_DEBUG OFF)
if (OpenCASCADE_BUILD_WITH_DEBUG)
  add_definitions (-DOCCT_DEBUG)
endif()
set (OpenCASCADE_BUILD_SHARED_LIBS ON)
set (OpenCASCADE_BUILD_TYPE "Release")

# Use of third-party libraries
set (OpenCASCADE_WITH_TCL ON)
set (OpenCASCADE_WITH_FREETYPE ON)
set (OpenCASCADE_WITH_FREEIMAGE ON)
if (OpenCASCADE_WITH_FREEIMAGE)
  add_definitions (-DHAVE_FREEIMAGE)
endif()
set (OpenCASCADE_WITH_GL2PS ON)
if (OpenCASCADE_WITH_GL2PS)
  add_definitions (-DHAVE_GL2PS)
endif()
set (OpenCASCADE_WITH_TBB ON)
if (OpenCASCADE_WITH_TBB)
  add_definitions (-DHAVE_TBB)
  if (MSVC)
    add_definitions (-D__TBB_NO_IMPLICIT_LINKAGE)
    add_definitions (-D__TBBMALLOC_NO_IMPLICIT_LINKAGE)
  endif()
endif()
set (OpenCASCADE_WITH_VTK OFF)
if (OpenCASCADE_WITH_VTK)
  add_definitions (-DHAVE_VTK)
endif()

if (NOT WIN32)
  add_definitions(-DOCC_CONVERT_SIGNALS)
endif()

if (MINGW)
  add_definitions(-D_WIN32_WINNT=0x0501)
endif()

This should be analyzed and appropriate solution is to be implemented.

5) Bad workaround about VTK's dependency on DirectX libraries on Windows.

a) Probably this dependency is indeed not needed in the VTK config file. Indeed, quick analysis shows that that DirectX features are used internally in a single VTK class which header is not exported. So, d3d9 library is used implicitly and d4d9.lib is not needed at linkage time when you build OCCT. In runtime this works just because most likely DirectX is installed on the workstation, into the Windows system directory. Only if DirectX isn't installed there will be most probably a problem in runtime with loading of related OCCT libraries.

b) On the other hand, hack used by OCCT for VTK detection procedure does not seem good. It supposes that Microsoft SDK was installed to the "C" drive, moreover, into the hardcoded directory. However, it can be installed to another drive and even to another directory. For example, on my workstation I have SDK installed on drive "D". So, if I build VTK on my computer and then give it to somebody else, that "somebody" will not be able to build OCCT, just because above mentioned hack will not work.

c) VTK, depending on the way it is configured, can depend on other third-party products, e.g. hdf5, libxml2, python, freetype, gl2ps. The path to these products can be also hardcoded into the VTK config files. Should we implement similar workaround as for DirectX for these products also?


Steps To ReproduceConfigure, generate, build and install occt via CMake.

File OpenCASCADECompileDefinitionsAndFlags-CurrentConfigurationName.cmake should be installed with all other OpenCASCADE config files into ${INSTALL_DIR}/${INSTALL_DIR_CMAKE}.
TagsNo tags attached.
Test case number

Relationships

child of 0027301 closedabv CMake: export targets for OCCT 

Activities

git

2016-04-05 12:39

administrator   ~0052381

Branch CR27344 has been created by ski.

SHA-1: c3811d0af557ab852d03f7472e1e49bbcbf0f387


Detailed log of new commits:

Author: ski
Date: Tue Apr 5 12:38:53 2016 +0300

    0027344: Configuration, CMake: bugs with detecting third-party products
    
    Information messages for TCL/TK search are corrected.

ski

2016-04-05 12:40

developer   ~0052382

Last edited: 2016-04-05 12:40

Bugs №2 and №3 are fixed in 0027301

abv

2016-04-05 16:47

manager   ~0052403

Moved to version 7.1.0.

Points (2) and (3) are fixed in context of 0027301.

Point (5) is addressed within 0027209: Direct3D library is searched by regexp thus should work for any version of the library and regardless of its install path. Note that unlike HDF5 and other dependencies, dependency on Direct3D cannot be disabled in VTK build, that is why we find it reasonable to address this issue on OCCT side (OCCT user does not need to have Direct3D SDK installed if he wants to use VTK!).

Points (1) and (4) are still pending.

Note on point (4): in order to support multiple configurations installed in the same path, configuration-specific options should likely be put in separate file, like it is done for export (target) files. The right way to do this is still unclear.

git

2016-04-21 13:49

administrator   ~0053472

Branch CR27344 has been updated forcibly by ski.

SHA-1: 7325a90024711211120d3ddd1a82353ef4ab7268

git

2016-04-21 14:43

administrator   ~0053474

Branch CR27344 has been updated forcibly by ski.

SHA-1: 213651a5790059b97fd26331d5e5213598caad87

git

2016-04-27 16:08

administrator   ~0053637

Branch CR27344 has been updated forcibly by ski.

SHA-1: b22abec0b6fca51580a08b8a154d8cc4c01d3ba1

git

2016-04-27 16:15

administrator   ~0053638

Branch CR27344 has been updated forcibly by ski.

SHA-1: 071ca0fab4c2f223bdba4925b65e1f8899c06a6c

git

2016-04-27 17:22

administrator   ~0053649

Branch CR27344 has been updated forcibly by ski.

SHA-1: 5f8b5e60e9d577e71a0439f7f19829aabae28acf

git

2016-04-28 16:12

administrator   ~0053688

Branch CR27344 has been updated forcibly by ski.

SHA-1: c7e281eb3dd3e545a7c08a3be1d4ee19ae094469

git

2016-04-29 10:59

administrator   ~0053721

Branch CR27344 has been updated forcibly by ski.

SHA-1: 16f375b2ef0a3a63e3c23c8d23862c47eadcf5c1

ski

2016-04-29 12:13

developer   ~0053725

Dear abv,

please review.

abv

2016-05-30 14:32

manager   ~0054537

No remarks, please test

git

2016-05-30 18:22

administrator   ~0054547

Branch CR27344 has been updated forcibly by inv.

SHA-1: 9e10821c98c8f07461b5d076ad2e24a3c03bdba5

git

2016-06-03 13:12

administrator   ~0054668

Branch CR27344 has been deleted by inv.

SHA-1: 9e10821c98c8f07461b5d076ad2e24a3c03bdba5

Related Changesets

occt: master a3d2cb24

2016-04-05 09:38:53

ski


Committer: bugmaster Details Diff
0027344: Configuration, CMake: bugs with detecting third-party products

Information messages for TCL/TK search are corrected.

Compile definitions were added to OpenCASCADEConfig.cmake file
Affected Issues
0027344
mod - adm/cmake/tcl.cmake Diff File
mod - adm/cmake/tk.cmake Diff File
add - adm/templates/OpenCASCADECompileDefinitionsAndFlags.cmake.in Diff File
mod - adm/templates/OpenCASCADEConfig.cmake.in Diff File
mod - CMakeLists.txt Diff File

Issue History

Date Modified Username Field Change
2016-04-04 12:04 vsr New Issue
2016-04-04 12:04 vsr Assigned To => bugmaster
2016-04-04 12:05 vsr Description Updated
2016-04-04 13:44 abv Assigned To bugmaster => ski
2016-04-04 13:44 abv Status new => assigned
2016-04-05 09:17 abv Relationship added child of 0027301
2016-04-05 12:39 git Note Added: 0052381
2016-04-05 12:40 ski Note Added: 0052382
2016-04-05 12:40 ski Note Edited: 0052382
2016-04-05 16:47 abv Note Added: 0052403
2016-04-05 16:47 abv Target Version 7.0.0 => 7.1.0
2016-04-21 13:49 git Note Added: 0053472
2016-04-21 14:21 kgv Summary Configuration, CMake: bugs with detecting third-party products => Configuration, CMake - bugs with detecting third-party products
2016-04-21 14:43 git Note Added: 0053474
2016-04-27 16:08 git Note Added: 0053637
2016-04-27 16:15 git Note Added: 0053638
2016-04-27 17:22 git Note Added: 0053649
2016-04-28 16:12 git Note Added: 0053688
2016-04-29 10:59 git Note Added: 0053721
2016-04-29 12:13 ski Note Added: 0053725
2016-04-29 12:13 ski Assigned To ski => abv
2016-04-29 12:13 ski Status assigned => resolved
2016-04-29 12:13 ski Steps to Reproduce Updated
2016-05-30 14:32 abv Note Added: 0054537
2016-05-30 14:32 abv Assigned To abv => bugmaster
2016-05-30 14:32 abv Status resolved => reviewed
2016-05-30 18:22 git Note Added: 0054547
2016-06-01 12:39 bugmaster Status reviewed => tested
2016-06-03 12:50 bugmaster Changeset attached => occt master a3d2cb24
2016-06-03 12:50 bugmaster Status tested => verified
2016-06-03 12:50 bugmaster Resolution open => fixed
2016-06-03 13:12 git Note Added: 0054668
2016-12-09 16:31 aiv Status verified => closed
2016-12-09 16:37 aiv Fixed in Version => 7.1.0