Archived issue #0009457
Avoid usage of environment variables
Description
Proposal (summary)
This idea is inspired by message by Philippe Carret of OCC forum (see
http://www.opencascade.org/org/forum/thread_6861)
Currently OCCT and derived applications require that a number of environment
variables were
correctly installed. Thus the user has either to modify global settings on the
wokstation, or use
bat files (or scripts on UNIX), which both methods are not very convenient.
The proposal is to provide a means to define the necessary settings by using
alternative methods,
thus avoiding usage of environment variables:
- registry on WNT
- specific configuration file on UNIX (e.g. $HOME/.occtconfig)
Naturally, the possibility to use environment variables should be kept for
compatibility
An additional proposal is to provide some GUI utility to manage the whole set of
configuration
variables. This shall make user's life more easy.
Expected benefits
Better user comprehension and easier OCCT installation and configuration.
Improved usability of
OCCT in applications.
This idea is inspired by message by Philippe Carret of OCC forum (see
http://www.opencascade.org/org/forum/thread_6861)
Currently OCCT and derived applications require that a number of environment
variables were
correctly installed. Thus the user has either to modify global settings on the
wokstation, or use
bat files (or scripts on UNIX), which both methods are not very convenient.
The proposal is to provide a means to define the necessary settings by using
alternative methods,
thus avoiding usage of environment variables:
- registry on WNT
- specific configuration file on UNIX (e.g. $HOME/.occtconfig)
Naturally, the possibility to use environment variables should be kept for
compatibility
An additional proposal is to provide some GUI utility to manage the whole set of
configuration
variables. This shall make user's life more easy.
Expected benefits
Better user comprehension and easier OCCT installation and configuration.
Improved usability of
OCCT in applications.
Public activity
4 archived notes
Participants are labeled by their role within this record.
Andrey,
It seems the bug became foul (2005 year...).
Do you want to analyze it once again or may be better to close it?
What is your decision?
It seems the bug became foul (2005 year...).
Do you want to analyze it once again or may be better to close it?
What is your decision?
Sergey, please consider this issue as a starting point for improvement to make OCCT usable without necessity to set environment variables.
I propose the following steps:
1. Find and document all environment variables currently used by OCCT
- Check OCCT documentation (Overview, FC UG) for this list
- Search code for getenv(), OSD_Environment
- Make up-to-date list of used variables
- Propose which environment variables are not useful to be removed
2. Identify environment variables which specify location of resource files and thus are required for OCCT to operate correctly. For these, find good way to make the code work without environment variables.
My idea is that necessary files can be found automatically using knowledge of possible layouts of OCCT binaries and resources.
Naturally, we will need to enumerate and document these supported layouts, for instance:
- Windows / MSVC development layout: binaries in ./win32/vc*/bin*, resources in ./src/*Resources
- Possible install layout: binaries in ./bin, resources in ./res
- Possible Linux install layout: binaries in /opt/occt*/bin, resources in /opt/share/occt
- etc.
3. Implement necessary changes in OCCT (I suppose some supporting class shall be created and then used in all occurrences). Ensure that DRAW works well without preliminary environment settings in all configurations
4. Make corresponding changes in samples (though it will likely be necessary to specify location of OCCT build, this could be made on CMake configuration step)
I propose the following steps:
1. Find and document all environment variables currently used by OCCT
- Check OCCT documentation (Overview, FC UG) for this list
- Search code for getenv(), OSD_Environment
- Make up-to-date list of used variables
- Propose which environment variables are not useful to be removed
2. Identify environment variables which specify location of resource files and thus are required for OCCT to operate correctly. For these, find good way to make the code work without environment variables.
My idea is that necessary files can be found automatically using knowledge of possible layouts of OCCT binaries and resources.
Naturally, we will need to enumerate and document these supported layouts, for instance:
- Windows / MSVC development layout: binaries in ./win32/vc*/bin*, resources in ./src/*Resources
- Possible install layout: binaries in ./bin, resources in ./res
- Possible Linux install layout: binaries in /opt/occt*/bin, resources in /opt/share/occt
- etc.
3. Implement necessary changes in OCCT (I suppose some supporting class shall be created and then used in all occurrences). Ensure that DRAW works well without preliminary environment settings in all configurations
4. Make corresponding changes in samples (though it will likely be necessary to specify location of OCCT build, this could be made on CMake configuration step)
In context of step 1, please note message of user Timo at
www.opencascade.org/org/forum/thread_24757/:
Dear Forum supervisor,
according to the OCC 6.6.0 release notes the CSF_GraphicShr is not used anymore.
But it is still docmented in the section on System Environment Variables in "Open CASCADE Technology Overview":
"CSF_GraphicShr is required to define the path to the TKOpenGl library;"
[signature removed]
www.opencascade.org/org/forum/thread_24757/:
Dear Forum supervisor,
according to the OCC 6.6.0 release notes the CSF_GraphicShr is not used anymore.
But it is still docmented in the section on System Environment Variables in "Open CASCADE Technology Overview":
"CSF_GraphicShr is required to define the path to the TKOpenGl library;"
[signature removed]
The need of using environment variables has been eliminated by #0027258. The variables that are still relevant seem to be correctly documented in Overview. If necessary, the client application can easily configure this environment using platform-specific means. Thus closing the issue
Related records