|
Autoconfiscating
Open CASCADE
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 library, you must use a compiler with it. If you
don't use the same version of the same compiler that Matra used to build
OCC, 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++ classes use 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.
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!
Introduction
to GNU Autotools:
Documentation for Autotools with Open CASCADE
How
to build:
Check the build instructions page.
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.
It is my intention to integrate all of these changes
into Matra's main CVS repository when they are finished.
This will be a major improvement in the current state of Open CASCADE.
I have recently gotten assurances from Matra Datavision employees
that this work will be incorporated into the main CVS repository.
Update: The entire project was handed off
to the Open CASCADE developers at Matra on April 30, 2001.
I have not recieved any notification from Matra that they are using
this work, nor have Matra's CVS sources been updated with the new
build system.
This project will remain on SourceForge until the time that Matra
has fully incorporated Automake, Autoconf and Libtool into their
CVS repository sources.
If you are considering becoming a contributor to this project
but unsure of it's future, I assure you that if there is anything
of use to anyone in this project, it will remain available.
www.opencascade.org
www.opencascade.com |
