Wed, 01/30/2002 - 16:23
This page was created to aid Open CASCADE developers in porting and configuring Open CASCADE (OCC) on currently unsupported platforms. This page also includes descriptions and some fixes for common problems
implementing OCC.
Why is a configure script needed?
Currently users have a tough time getting a simple example to run because of several reasons.
Because Open CASCADE is a set of libraries, you must use a compiler and your own source with it. If you don't use the same version of the same compiler that Matra used to build CASCADE, you are likely to have problems. If you don't have the same compiler, i.e. you don't have an ABI compatable compiler, you are completely out of luck. The reason is that the OCC interface is C++ classes. C++ classes provide the most intuitive and usable interface for a library such as this one, but C++ uses name mangling of functions to allow for overloading. If the name mangling schemes are not identical (sometimes this changes between versions of the same compiler) then the linker will be looking for the wrong names and any attempt to resolve symbols will fail.
For a particular platform, Open CASCADE binaries are linked to a particular Tcl/Tk library version. Under IRIX, this is version 7.5i. Doesn't sound so bad? Try to download an IRIX binary for Tcl version 7.5i, there aren't any available! You would have to download the Tcl 7.5 source, compile it, install it, and then rename or link the shared libraries to the name libtcl7.5i.so.
Autoconf handles this problem by linking to whatever you have installed.
If you don't have a supported platform, you are also out of luck. With Autoconf, the features of the system are checked when the source tree is 'configure'd. Often times a new platform can be compiled with no changes whatsoever. GNU Libtool provides the only portable mechanism for using shared libraries, if Libtool has been ported, you shouldn't have any problems building and using Open CASCADE. Note also that Libtool supports many more systems than Open CASCADE currently does. Another reason to use Autoconf is that it will continue to be usable, as compilers and development tools evolve, Autoconf will evolve to handle these yet to be defined issues.
Autoconf is the "Open Source" way, most Free software uses it as well as many open source and proprietary applications and libraries.
The idea is to use GNU Autoconf, GNU Libtool and GNU Automake to create a portable bourne shell script "configure" that will generate makefiles and a configuration header file. The configure script will test the system in a number of ways and create the configuration header "config.h" based on these tests. Currently, there is only one developer working on this project, so if you would like to help test please volunteer!
To do list: Shared installations of Open CASCADE need a better way to determine the platform they are running on. The 'uname' command is far too coarse to be used for this purpose, as all Linux systems reply with "Linux" no matter what processor they are running on. Preferably the GNU Config scripts, config.guess and config.sub would be used for this as they have the fine-grained control needed to sort out the proper binaries to use on any particular platform.
Running WOK requires users to have TclX and expect installed as shared libraries, perhaps these could be auto-configured when these libraries are present in the source directory. This would be a great project for someone who is just getting started because it would probably not involve changing anything, just adding some checks and calls to "configure.ac".
Add Autoconf macros for Java support. Open CASCADE uses Java in a few places, but the current configure script doesn't look for a Java
compiler, only the Jni headers. Automake and Autoconf have Java support, so it is possible to integrate this as well. The TKjcas library is not built if jni.h is not found, the build won't stop in FoundationClasses it the headers aren't found.
Test on every platform possible.