Open CASCADE, the 3D modelling kernel
3D modeling & numerical simulation

Search the Forums
See All Topics
 

CMake experimental OCC builder

CMake experimental OCC builder
Thomas Paviot 2010/01/22 13:10
Hello everybody,

For about a couple of weeks (well, almost), I've been trying to move the pythonOCC build system from distutils to CMake, in order to have a real multiplatform builder and save many *many* hours of work. I contributed a CMake builder to Fotis' salomegeometry project, which works quite well. A lot of people here already complained about the automake builder/installer currently used by OCC (Unices); Roman Lygin reported (http://www.opencascade.org/org/forum/thread_17893/) a few issues with Windows/MSVC as well. Indeed, we all here expect a multiplatform build system that would automate everything we do manually. I then started to work on a CMake based installer (I know there are other build tools, but I had to choose one, and already had bad experience with SCons).

Here is attached a text file named CMakeLists.txt. CMake parses this file, and generates project files according to the Generator you choose (for instance VS2005 under win32, Unix Makefiles under Unix). CMake 2.6 or higher is required (see http://www.cmake.org). Detailed instructions about the 'HowTo' are in the file header. Note that projects using CMake usually split this script in many different files located all over the source code. The file attached is a 'monolithic' script.

This attempt is a very first draft, and the result of only 4 hours of work, so don't expect to be able to compile the whole solution (only TKBRep and TKernel toolkits can be built, still linkage errors). This script can be considered as an outline, but I hope you'll however be interested in this work and can contribute in any way to improve it. I tried to comment the code as clearly as possible, and inserted #TODO tags. This file is distributed under the terms of the OCCT Public License 6.3.

Having a source code version control tool would be a very good thing( maybe in 2010?; in the meantime, feel free to attach patches to your replies.

Best Regards,

Thomas
You have to be logged in to download the attached file
Thomas Paviot 2010/01/22 17:58
This version should work better: TKernel, TKMath, TKG2d and TKG3d build/compile properly.
You have to be logged in to download the attached file
Arthur Magill 2010/01/23 16:37
Hi Thomas,

This is a fantastic start - how do you find the time?

I've tried your cmake file here (Debian testing, cmake 2.8). It works fine after one minor tweak. On line 49, change

FIND_PACKAGE(Tcl)

to

FIND_PACKAGE(TCL)

and it works. I haven't tested on other Linux distros, but I guess you don't see it because Windows isn't case sensitive.

Thanks again - I'll try contribute something to this one!

Arthur
Thomas Paviot 2010/01/27 21:19
Hi Arthur,

Thank you for this feedback. I use to develop with MacOSX since I bought a new MacBookPro laptop, and definitely dropped out Windows as a development platform. But surprisingly, MacOSX is not as case sensitive as Linux. I experienced the following inequation:
case_sensitivity_Windows < case_sensitivity_MacOSX < case_sensitivity_Linux ! Weird, don't you think?

I'll try to find time to go further in the development, but I'm quite busy these days.

Thomas
Roman Lygin 2010/01/27 19:09
Thomas,

I applaud your effort! Really ! At some point I was thinking about cmake but did not come up to experimenting with it. Now, when I have to maintain a couple of dozens of MSVS projects + for VS2005 and VS2008 for CAD Exchanger, maintaining consistency (across projects and Visual Studio versions) is becoming a non-trivial task. So I am thinking more seriously to adopt cmake or something else. Briefly googling I found out that this model of working in VS IDE and manage files through cmake seems quite feasible and broadly adopted (despite first hiccups of adding files into VS than into CMakeList.txt).

Do you know if cmake builds can be customized - invoking some external tools for files (e.g. Qt moc or resource compiler, or copy dlls as a post-build step) ?

Kudos again for driving this!
Roman
Thomas Paviot 2010/01/27 21:38
Hi Roman,

Thanks for you enthusiastic support. Coming from you, I feel honored!

As you did, I also looked around for a bulld system able to automate the compilation stages. Unlike SCons, CMake doesn't require you learn a new programming language (SCons can actually be considered as a python package). It's a very understandable scripting language (it reminds me my first experiences with BASIC, a long time ago). One important point is also the integration with CTest and CPack (packaging solution that can generate .deb/.rpm/OSX bundles/NSIS based Windows installers etc.). CMake + Ctest + CPack can be seen as a complete toolsuite from your source code to the user desktop. I will investigate this further as soon as I have time.

I'm still a beginner with CMake, so it's difficult for me to answer your question precisely. I can just say that CMake is the build system for KDE4. I then guess that the integration with Qt, pre/post-install scripts and all that stuff is something pretty well handled by CMake, but it's so far just an assumption.

Best Regards,

Thomas
Zettler 2010/01/29 12:39
Hello,

maybe I can contribute to this discussion. Cmake can be used to invoke external tools as well. For example the whole FreeCAD project is based on cmake. Especially the integration with Qt and VS is nearly perfect. Also the generator for KDevelop and other Linux RD systems is perfectly integrated.

I personally work with cmake for all my projects since 4 years and was never disappointed.

Just give it a try as its also very easy to learn.

All the best,
Joachim
Thomas Paviot 2010/02/08 10:51
Hi Joachim,

Thanks for this useful info. I'll have a look to the way you use CMake with OCC.

Do you also use CPack for the freecad project? According to me, one of the major advantage of CMake (over SCons for instance) comes from this strong integration with packaging/testing.

Best Regards,

Thomas
Hugh Sorby 2010/03/12 01:25

Hi Thomas

I have continued your work on CMake-ifying OpenCASCADE. I have also setup a repository with unfuddle to help with this.

In this repository I have put in your CMakeLists.txt file that I have modified a bit, an occ_config.h.in file for the configure file and a patch for converting a vanilla OpenCASCADE6.3.0 source from using a config.h file to an occ_config.h file for the configuration information.

Because of the free nature of this repository hosting I can have only myself and one other person with access (I hope). So if you would like to see what I have done e.t.c. let me know here and I can drop you an email with access information. I don't mind sharing this information with anybody else interested either.

I am concentrating on building for a 64 bit Linux system right now but after that I will probably move on to winblows and then mac.

Of course if you have already finished CMaking OpenCASCADE then ignore this.

Cheers.
Roman Lygin 2010/03/12 06:23
Hi Hugh,

Yep, I would be interested. I tried to experiment with CMake but could not really reach acceptable results in reasonable time.
So if you could demonstrate how to convert at least one library (say TKernel) preserving all OCC settings (dir structure, and external commands invoking) that would be very helpful. My current interest is Windows, so if you don't have any other priorities you could start with that ;-).

Thanks for your efforts.
Roman
Thomas Paviot 2010/03/12 06:37
Hi Hugh,

I did not have time to go further on the CMake part these last weeks. If I had finished, I would have post a thread on this forum.

I'm then happy that this first draft was useful for you, and I'd really like to see the current status of the project. According to me, the config.h file must be generated by CMake (according to the result of the checks performed during the configure step). The other issue is to split the CMakeLists.txt into many CMakeLists located in src subdirectories (I think one CMake file per library generated): I indeed noticed that the whole solution is regenerated whenever one file is modified.

When this is done, I think we should have to find OS specialists (Mac, Win, Lin, Solaris, 32 and 64 bit etc.) in order to tune the building system according to the machines/compilers.

At last, thanks for sharing your work,

Best Regards,

Thomas
Thomas Paviot 2010/03/12 06:42
My email address: tpaviot_at_gmail_dot_com
Hugh Sorby 2010/03/17 04:49

Right I have set up a googlecode svn repository if anyone is interested. I'm very new to googlecode so bear with me. I think I can add you in as a contributor/committer if I have an email address. Anyway you can at least get a read only copy and post patches here.

To get a read-only copy:

svn checkout http://opencascade-cmake.googlecode.com/svn/trunk/ opencascade-cmake-read-only

at the moment there exist three files
1. CMakeLists.txt
2. occ_config.h.in
3. OpenCASCADE6.3.0.patch

You have to move/softlink CMakeLists.txt to /where/you/put/OpenCASCADE6.3.0/ros. Move/softlink occ_config.h.in /where/you/put/OpenCASCADE6.3.0/ros/inc. Then you need to apply the patch so that OpenCASCADE stops looking for config.h and uses occ_config.h instead.

After doing that you are ready to try building with CMake. You might like to do it like this for example:

mkdir /where/you/put/OpenCASCADE6.3.0/build
cd /where/you/put/OpenCASCADE6.3.0/build
cmake ../ros
make <- Wait a long time because you just enabled everything
make install <- haven't tested this but you could get some libraries in a funny place on your hard drive

If you are on linux you might like to use ccmake and modify some variables (like turning off WOK, I might make this the default). There are of course other visual cmake tools so feel free to use and get back with issues.

Hugh.
softminer 2010/05/12 16:28
Perfect work.Thanks
Thomas Paviot 2010/04/28 21:50
Hi,

Thanks to the amazing work of Hugh, the experimental CMake builder for OCC was much improved these last weeks (just have a look at http://code.google.com/p/opencascade-cmake/ , in the source/changes section).

I will have time, in the next couple of weeks, to focus on the Windows specific issues (Hugh works on Linux) and I have questions related to the MSVC compiler settings (I'm not a C++ specialist and a bit confused with MSVC numbering : MSVC6, 7,8, VS2003, 2005, 2008 and now 2010 - so please excuse the possible mistakes in the following):
- in the OCC6.3.0 packaged distribution for Windows, there are available projects files for MSVC6, MSVC7 and MSVC8. Did some of you experiment 'better' (at least different) compiler settings or should they just be copy/pasted to CMake ? Should we implement conditional settings according to performance optimization, code size optimization, threading robustness etc.? Does this last question make any sense?
- did you ever compile OCC with a newer MSVC compiler release that is not supported by OCC6.3.0 ? What settings did you use ?
- did you try to compile OCC with other compilers (Borland, Mingw) etc.? What did you learn from it?

Many thanks for your advices and suggestions. I will not have time/skills to test all compilers : I trust your experience and skills.

Thomas
Thomas 2010/04/29 08:02
I usually compile with VS 2008 SP1, and many times as static lib . A switch to get a static version of the libraries (maybe with different output dirs) would be very welcome. To do a static version you just need to change one DEFINE in every project.

Also, I managed to get a single solution file instead of many ones (but you need Visual Assist X to load it in the IDE :)

It would be usefoul to exclude from the compilation DRAW and WOK, since they require TCL/TK and I don't usually need them to use with a C++ project.

I have pushed a bit the optimization flags (i.e. use SSE but not SSE2, more aggressive optimization level and inlining, etc...) and everything worked well.

In a bunch of days I will try the CMAKE system, and will send you some feedback! Thank you!
Thomas 2010/05/12 11:00
Hello,
I've began to test the cmake experimental builder and it works very well.
To build a STATIC lib, in WINDOWS an additional define is required:

HAVE_NO_DLL

Since I don't know where to put exactly the patch ADD_DEFINITIONS("-DHAVE_NO_DLL")
I 've put it at line 113 of trunk version

IF( OPENCASCADE_BUILD_SHARED_LIB )
     SET( OPENCASCADE_LIBRARY_TYPE SHARED )
     SET( OPENCASCADE_INSTALL_TYPE LIBRARY )
     IF( WIN32 )
          SET( OPENCASCADE_INSTALL_TYPE RUNTIME )
     ENDIF( WIN32 )
ELSE( OPENCASCADE_BUILD_SHARED_LIB )
     SET( OPENCASCADE_LIBRARY_TYPE STATIC )
     SET( OPENCASCADE_INSTALL_TYPE ARCHIVE )
+     IF( WIN32 )
+          ADD_DEFINITIONS("-DHAVE_NO_DLL")
+     ENDIF( WIN32 )
ENDIF( OPENCASCADE_BUILD_SHARED_LIB )

Anyway, I don't think it's the appropriate location! Could you give me any hint? Do you think it's correct to add such a flag? (I got compilation problems otherwise).
Thomas 2010/05/12 11:16
Also, to make it compile with HAVE_NO_DLL, OpenGL_tgl_all.h and OpenGL_Extension.h require a modification (the same)

#if defined(WNT) && !defined(HAVE_NO_DLL)
.
.
.
#else
.
#endif

+ #if defined(WNT) && defined(HAVE_NO_DLL)
+ #define STRICT
+ #include <windows.h>
+ #endif

This probably is a bug in OCC, because windows.h should be included even if HAVE_NO_DLL is defined.
Werner Mayer 2010/09/13 19:26
Hi,

in the past few days I worked on a port to the MinGW compiler. As a first step I wanted to build shared libraries using MSVC since this compiler almost needs the same defines as the MinGW compiler.

After fixing some issues (a wrong library name was used odbcpp32 instead of odbccp32 and some missing dependencies of the projects which lead to many linker errors) I also added a block to set the correct compiler defines on a per file basis. These defines are needed to control the __declspec(dllexport) and __declspec(dllimport) stuff for compilers on Windows and thus to create shared libraries.

After these few changes I was able to build the complete library (but without WOK, DRAW and the JAVA binding) using Visual Studio 2008.

In the second step I started to build the sources using the MinGW compiler. Several files needed to be changed therefore, for most of them the Standard_IMPORT macro had to replaced by Standard_EXPORTEXTERN.

For some other files I had to workaround some limitations of missing features of the Windows API of MinGW. After all these changes I was able to build the complete OCC library using MinGW.

Attached is the modified CMake script and a patch for the MinGW port. Thomas or Hugh you can add them to your google project if are interested.

Regards
You have to be logged in to download the attached file
Thomas Paviot 2010/09/14 11:26
Hi Werner,

It's an excellent news you managed to get OCC compiled with Mingw. Indeed, it's much more convenient to compile OCC/OCC based software on different platforms using the same compiler (i.e. gcc). Using both Linux/gcc or MacOSX/gcc and Win32/VS2003,2005,etc. is not consistent, and I was hoping that someone finally take time to port OCC to Mingw. Thank you for this contribution!

I applied your patch and committed code to the opencascade-cmake source code repository, but did not test the process however (will do it asap). Which version of Mingw do you use? Did you notice any strange behavior while using the OCC libraries compiled with Mingw (although it's impossible to validate the whole library without any suite of unit tests)?

Best Regards,

Thomas
Werner Mayer 2010/09/14 14:22
Hi Thomas,

first I tried an older MinGW version which was part of a Qt Creator installation. The version was 3.14 and the gcc version there was 3.4.5. Before trying your CMake solution I did it the conventional way, i.e. I used the automake-based approach. But there I ran into thousands of linker errors when building the first module TKernel. According to some error messages there and some comments from a MinGW-related NG my MSYS/MinGW installation seemed to be broken somehow.

Then I set up a complete new MSYS/MinGW installation with the latest version I have found on Sourceforge. The MinGW version is 3.18 and the gcc version is 4.5.0. Doing it again with automake I still had one remaining linker error which I wasn't able to solve properly. After some time I gave up and tried the CMake-way...

Although the CMake approach appeared to be much faster for me because I didn't have to touch dozens of Makefile.am's I still encountered some stumbling blocks:

* when starting the make command it always took almost a minute before it started the build process. This is probably because make always checks the dependencies to other targets and also if there are source files which need to be rebuilt. Some Makefiles have a size of 6MB!

* from time to time I got an error like "cygwin heap error". I don't remember the exact error text but just restarting make solved this already

* another problem I met is that parallel builds don't work very well on MSYS. When I started make e.g. with the option -j4 then after some time one make process was hanging and I had to kill it. Doing a -j2 seemed to work much more reliably.

* the hardest problem to solve, however, was that for a couple of modules I got the error: "Bad file number". The comments from Paul Jimenez in this thread http://www.opencascade.org/org/forum/thread_17040/ were quite helpful.
I found an elegant way to solve this issue without too much work. For each target all the build rules are inside a file build.make and almost at the end of the file there is a variable (e.g. TKGeomAlgo_OBJECTS) that stores all the name of the object files and then further down there comes a line of the form
g++ <options> -shared -o libTKGeomAlgo.dll $(TKGeomAlgo_OBJECTS) <libs>

Since TKGeomAlgo_OBJECTS contains too many characters the linker stopped the creation of the DLL. The trick now is to split the block TKGeomAlgo_OBJECTS into smaller pieces, create a static library first, unpack this static library so that all .obj files are inside the same directory and then finally create the shared library out of the .obj files. This means that the build.make file must be changed to look like:

TKGeomAlgo_OBJECTS = \
...

TKGeomAlgo_OBJECTS2 = \
...

ar rcs win32/libTKGeomAlgo.a $(TKGeomAlgo_OBJECTS1)
ar q win32/libTKGeomAlgo.a $(TKGeomAlgo_OBJECTS2)
...
ar x win32/libTKGeomAlgo.a
g++ <options> -shared -o libTKGeomAlgo.dll *.obj <libs>
rm -f *.obj

As far as I can remember I have to apply this trick for the targets TKGeomAlgo, TKBool, TKIGES, TKSTEPBase and TKV3d and except of the latter two it was sufficient to split the big block into two pieces.
However, for the TKSTEPBase target (which I had to split into four blocks) I had to do an additional step because even when all *.obj files lied in the same directory the amount of characters of all file names was still too much. After renaming these files to something shorter solved also this problem.

So, after all a build with MinGW cannot be done completely automatically. There are still a few user interactions required to get it working.


As developer of the FreeCAD project I needed the DLLs for Foundation, Modeling Data&Algorithms and Data Exchange and as far as I can see these DLLs seem to work fine. I didn't test all the functionalities there but the few ones I have tested work without problems.

Cheers,
Werner

Thomas Paviot 2010/09/14 15:34
"""
* when starting the make command it always took almost a minute before it started the build process. This is probably because make always checks the dependencies to other targets and also if there are source files which need to be rebuilt. Some Makefiles have a size of 6MB!
"""

The CMake building process is driven by the script CMakeLists.txt. Usually, in big projects, there are many CMakeLists.txt files (one in each subfolder for instance). The dependency checking is then much quicker (as well as the search for modified sources files). The "one big" solution we chose is then not the best one (if only one source file is modified, the whole project has to be recompiled).

However, we can consider that source files don't change very often! (it would be completely different if a subversion repository was available for OCC and if we had to compile the library each day).

In the meantime, the advantage of one big CMakeList is that it can easily be debugged/maintained. When the CMake based build process is mature enough, it will be possible to split it to different subfiles.

Cheers,

Thomas
Mark 2010/12/28 00:07
FindOpenCASCADE.cmake

If anyone builds an app with CMake, this file will be very helpful - it is used to find the location of include directories and libraries for a package.

It works on Debian Squeeze and Ubuntu 10.04. Hopefully it will work on windows but I haven't tested it.

Thomas, could you add it to opencascade-cmake?

Regards,
Mark
You have to be logged in to download the attached file
Yuriy Sinithin 2012/02/12 17:10
Hi, Werner!
It's a really cool to build OCC with mingw, also with mingw-w64 under Windows. I don't see your post before and start working for few days ago, make some pathches like your patch, but with define MINGW_CORRECTION, but I can't build librarys with "undefined references to `vtable Some_Package".

You are write that you change Standard_IMPORT macro with Standard_EXPORTEXTERN, but your patch don't have this changes. May you tell, how It's work for you ???
Werner Mayer 2012/02/13 18:32
> You are write that you change Standard_IMPORT macro with Standard_EXPORTEXTERN, but your patch don't have this changes. May you tell, how It's work for you ???
If you look at the file OpenCASCADE6.3.0-MinGW.patch you'll find more than two dozens of Standard_EXPORTEXTERN there.

Before posting my patch I double-checked that it contains really all required changes. However, I only tried it with the 32-bit version of MinGW, for the 64-bit version some further changes might be needed.

Do you get these linker errors for the OCC libraries or the libraries of your application where you _use_ the OCC libraries?
Yuriy Sinithin 2012/02/13 20:24
Now I'm try to build with last version of MingW, at this moment I'm pathed some more 4000 files, because new vesion of GCC return vtable error if not defined virtual ~destructor and if default constructor in *.lxx files. It's more difficult that I think before, but I'm trying.
Yuriy Sinithin 2012/02/13 20:35
Really I'm undestand that all functions that defined in *.hxx must be in *.cxx, if we don't have block of function then we have 'vtable error, and it's hardly because here is default OCC macros like IMPLENTED, and IMPLENTED_RTTI, it's not easy to decode and paste into *.cxx.
Yuriy Sinithin 2012/02/13 22:38
After I'm have Input virtual ~Destructor in all classes that GCC provide, now !!! Win 7 (64 bit) my graphic application get 25 mb of memory (!!!!!!! one month ago 64 Mb on startup with WinXP and 300 Mb after some working). And after two hour work with boolean, texturize, it's 36 mb. When I close the document, will return size 25 Mb. Memory leaks is gone !!!)))) But some new problems I have founded, something like Intersection algo don't work correctly, but HLR is worked, and Boolean. Maybe it's not a compiler options....
Yuriy Sinithin 2012/02/13 23:08
Find what going on. When I build all packages, make patch in Extrema_GExtCC.gxx. In OCC sources:

if (inverse = (type1 > type2)) {

And I have little change to :

if (inverse == (type1 > type2)) {

but after the MinDistance can't be correctly and I make how OCC was! It's so stupid question, but what this "(inverse = (type1 > type2))" can return ??? 0 or 1, or unsigned integer like Standard_Boolen ???? maybe always false ))
Thomas Paviot 2012/02/14 06:41
Hi Yuriy,

This thread is outdated. The experimental CMake builder for OCC has been integrated into OCE and was much improved.

Thomas
Yuriy Sinithin 2012/02/14 08:10
Ok
Adam Compeau 2010/05/05 20:25
Hello,

I am trying to get this to work in Red Hat Enterprise Linux 5 32-bit, and am encountering problems. It seems that I am missing some Java environment variables, causing CMake to fail. The problem is that I'm not sure where these three variables are supposed to point. I have the JDK installed. Here are the errors:


CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
JAVA_AWT_INCLUDE_PATH (ADVANCED)
used as include directory in directory /home/user/Desktop/OpenCASCADE6.3.0-cmake/ros
JAVA_INCLUDE_PATH (ADVANCED)
used as include directory in directory /home/user/Desktop/OpenCASCADE6.3.0-cmake/ros
JAVA_INCLUDE_PATH2 (ADVANCED)
used as include directory in directory /home/user/Desktop/OpenCASCADE6.3.0-cmake/ros


Any help would be greatly appreciated.
Adam Compeau 2010/05/05 21:02
Nevermind, I figured this out.

JAVA_INCLUDE_PATH = the include path to jni.h
JAVA_INCLUDE_PATH2 = the include path to jni_md.h
JAVA_AWT_INCLUDE_PATH = the include path to jawt.h
 
 
Latest news
  • OCCT Applications
  • Open CASCADE Technology 6.8.0 is available for download!
  • New features to enhance the development process

  • © OPEN CASCADE 2000 - 2014  |  Search  |  Contacts   |  Site map