OCE-0.3.0 released

Hello,

OCE 0.3.0 has been released. The CMake build system has been improved. It can be considered as mature and stable enough to be used to build OCE: it will be, from now, the only supported and maintained build system. As a consequence, outdated and unuseful autotools files, as well as MSVC project files were removed from the distribution (Borland Compiler project files are however still part of the project untill some fixes related to CMake/BDS are committed). A few other modifications deal with code cleanup, warning removals, mingw cross compilation fixes.

Here is the detailed changelog:

* Make CMake work with MSVC. This generator is special,
it generates both Debug and Release configurations.
[QbProg]

* Add an option to enable maximum warning levels
[QbProg]

* Improve handling of CMake options
[Hugh Sorby]

* Fix build failures with g++ 4.6
[Denis Barbier]

* Clean up CMakeLists.txt, remove unused macros.
[Mark Pictor]

* Create two config files, one is used during compilation,
another one is used when linking against OCE. The latter
contains fewer macros, and they are prefixed by OCE_ to
prevent name clashes.
[Mark Pictor]

* Start fixing compiler warnings.
[QbProg, Thomas Paviot]

* Create a bundle for MSVC
[QbProg]

* Fix cross compilation with Mingw. We were not able to
build visualization stuff previously.
[Muellni]

* Install an OCEConfig.cmake file so that programs can use
FIND_PACKAGE(OCE) to set variables to link against OCE.
[Muellni]

* Undefine Convex before it is used by OCE as a method or
function, this may be a macro defined by X11.h
[Thomas Paviot]

* Remove -DLIN from compiler flags. It still works on Linux,
and this caused crashes on Mac OSX.
[Thomas Paviot]

* Delete inc/TopOpeBRep_tools.hxx, this file is unused, and it
includes TopOpeBRepDS_tools.hxx which does not exist.
[Denis Barbier]

* Remove Autotools files for Unix and MSVC, CMake build system
works fine on these platforms. We keep Borland project
files for now, this IDE is not supported by CMake.
[Thomas Paviot]

Precompiled binaries are being packaged for both Windows and MacOSX. They will be available in a couple of days.

Best Regards,

Thomas

Arthur Magill's picture

Excellent news - well done guys! The transition to CMake has been really fast, and can only make building easier. You only forgot one thing Thomas - the URL for the project website:

https://github.com/tpaviot/oce

Thanks to the OCE team for all your hard work,

Arthur

Thomas Paviot's picture

OCE team has uploaded binary packages to the github repository: MSVC 8, MSVC 10 (both Win32/Win64 debug/release) and MacOSX SL 64 bit (release).

Just click the 'Download' button available from the OCE project page: https://github.com/tpaviot/oce (thanks Arthur for the URL).
Please report any issue.

Best Regards,

Thomas

P Dolbey's picture

Hi OCE team (sorry haven't registered yet)

What is the state of OCE 0.3.0 follwing the release of OCCT 6.5.1 - can it be applied over a new installation or is some work required (I suspect the latter is true)?

Pete

Thomas Paviot's picture

Hi Pete,

Wer're about to release 0CE-0.4.0 (planned for the 1st of July, we have so far alwayas honored out commitments regarind release dates). It will focus on quality assurance (warnings fixes for all compilers, bugfixes, unittests). Recent changes included in 6.5.1 will be merged to OCE just after this release, Denis Barbier will take care of it. We will ensure that our modifications over the 6.5.0 version are still valid.

We're looking forward to your registration! Sure you have so many interesting opinions/suggestions/code to share with us.

Thomas

Thomas Paviot's picture

Sorry, one spelling mistake per word is definitely too much, please read: "we have so far always honored our commitments regarding release dates". Next time I will switch on the light of my MacBook Pro keyboard!

Thomas

gpsunjp sun's picture

Why remove MSVC project files?

Thomas Paviot's picture

In OCE, MSVC project files are generated with CMake. There's no need to maintain these files anymore, so we removed them. Thanks to CMake, we achieved to get OCE much more portable than OCC since it can be compiled on most platforms (Win 32/64, Lin 32/64, MacOSX) without any platform specific tweak.

Thomas

P Dolbey's picture

Is anyone planning a static library version of OCCT?

Pete

QbProg's picture

OCE allows to build the library as static lib.
Just download the sources and set the appropriate configuration option in CMake

http://www.github.com/tpaviot/oce/

P Dolbey's picture

Excellent :)

Pete

Carlos's picture

Hi,

It compiles ok and the c# sample can be created but I have some problems when I run it. I think that the reason is related with Tkopengl.

Tkopengl is built as static library but OCC try to load it as a Dll. I suppose that the source code must be modified but I do not know know to do it.

Have you compiled OCE as static libraries successfully

Regards

QbProg's picture

this is possible, never tryed static libs + tkopengl

I will open a bug for this

Denis Barbier's picture

Does anybody know why TKOpenGl is dlopen'ed instead of linked at build time?

As DRAWEXE loads plugins at runtime, it does not make sense to build it statically. On the other hand, Modeling, OCAF and Data Exchange components can be built statically (if I remember correctly). But I do not see the point of static linking, so I did not test it extensively.

Forum supervisor's picture

Hello Thomas,

I shall notice that OCCT is already ported since many years to the most of platforms (see of our web page http://www.opencascade.org/getocc/require/ ), except may be MacOSX and it works well. OCCT releases are based on WOK that is portable and generates all needed compilation procedures.
For sure WOK is not the most modern and not so advanced as CMAKE, but we can't remove it in short term - our production process for certified OCCT versions still uses WOK.
But I shall say that CMAKE is a very good tool - since some time we also analyzed different compilation tools to consider alternative solutions to replace WOK.
And it's great that the community works in the same direction!
We really need to work together to improve OCCT and we really would be appreciate to get all your ideas and opinions and to discuss technical details...

Best regards,
Forum supervisor.

Thomas Paviot's picture

Dear Supervisor,

As you can read in my previous post, I never claimed or said that OCC is not ported. That would be clearly wrong, and I usually try as possible to take care to what I write. I only wrote: "we achieved to get OCE much more portable than OCC". It's not an asumption: it's a fact. Just browse the github repository, the commits and the release notes, you will realize this is a reality.

Of course we're still looking forward to setting up any kind of collaboration with you. As soon as you decided to drive, organize and laucnh the discussions, we'll bring you as much ideas and opinions as we can.

Best Regards,

Thomas

Denis Barbier's picture

Hello,

OCCT only suppports x86 and x86_64 CPUs; this may be fine to most users, but IMHO it can hardly be qualified as portable.

P Dolbey's picture

Funny, because it used to support Solaris, presumably under SPARC around the 5.2 release - don't know when platform support changed.

Pete

Denis Barbier's picture

To be honest, I have no idea whether legacy Unix systems are supported or not (Solaris, HPUX, AIX, etc), maybe they are still supported. On Linux, OCCT builds only on x86 and x86_64 CPUs, and it does not build on Hurd and (IIRC) also BSD, that was my point.