View Issue Details

IDProjectCategoryView StatusLast Update
0033858Open CASCADEOCCT:Configurationpublic2024-12-20 13:11
Reporteroan Assigned Todpasukhi  
PrioritynormalSeverityminor 
Status newResolutionopen 
Summary0033858: Configuration - Don't use absolute paths in the run scripts
DescriptionWhen OCCT is compiled somewhere outside the workstation where it is supposed to be used, e.g. by CI/CD, it becomes impossible to start DRAWEXE on target workstation, because all paths in env.{bat|sh} and custom.{bat|sh} are hardcoded with absolute paths corresponding to the file system of the machine where it was compiled.

This causes necessity to modify run scripts manually every time a new build is ready.

Usually, structure of the distribution looks like:
3rdparty
-> freeimage
-> ...
-> occt

i.e. all dependencies are located right on the same level with occt itself or nearby.

It is good to have some CMake option that allows usage of relative paths, e.g. variable pointing to some directory relative to occt's installation dir or CASROOT, or functionality comparing 3RDPARTY_DIR and INSTALL_DIR allowing to use relative path automatically if INSTALL_DIR corresponds to 3RDPARTY_DIR.
Among these two options, the second way looks better, because on Windows it is impossible to use relative paths pointing to a drive with another letter.

The following variables are influenced:
- CASROOT in env.{bat|sh} - e.g. on Linux it's absolute, but should be the same as aScriptPath as on Windows.
- THIRDPARTY_DIR in env.{bat|sh} (look more suitable if it points to "%CASROOT%/.." by default)

both of the above variables should be modifiable via custom_<ver>.{bat|sh} only and do not change inside env.{bat|sh} depending on the build configuration.

- All 3rdparty variables in custom_<ver>.{bat|sh}: behavior of this file seems to be undefined, at least on Windows - sometimes THIRDPARTY_DIR is used, sometimes explicit absolute paths.
TagsNo tags attached.
Test case number

Activities

dpasukhi

2024-12-20 13:11

administrator   ~0116916

Ongoing approach will be based on VCPKG layout which determinate 3rd-party structure.
For sure old approach will be still available, but new approach will be used more commonly after integration. It will helps to avoid any requirements to paths.

Issue History

Date Modified Username Field Change
2024-12-19 21:00 oan New Issue
2024-12-19 21:00 oan Assigned To => dpasukhi
2024-12-20 13:10 dpasukhi Target Version 7.8.1 =>
2024-12-20 13:11 dpasukhi Note Added: 0116916