View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0032268||Community||OCCT:Configuration||public||2021-03-30 14:47||2021-11-25 21:38|
|Summary||0032268: Configuration, CMake - a proposal for minimal build flag in CMake|
integrating OCCT libraries into our application we use only a subset of libraries and we use only algorithms, no visualization tools and services. This means also, that actually we have no dependencies to any 3rd party libraries - freetype, tcl, tk. At the same time, the current cmake file requires a developer to have these libraries.
Herewith I would like to propose an option for CMake to trigger a minimal build, which eliminates all dependencies to any 3rd party libraries and builds a set of libraries which represent the algorithmic part of OCCT.
The drawbacks of my current proposal:
1. Some cpp files are fully ifdefed - particularly the ones from Font package. Maybe better to move them to some other module
2. Currently I added a file MODULES_MIN, but maybe it is even more reliable to be able to accept a custom MODULES file
Advantages of my proposal:
1. It is possible a minimal viable product without additional 3rd party dependencies
2. It is easier to build a minimal set of libraries on some automated systems like Jenkins as they do not require any additional libraries to be installed
3. The proposed solution is just an option for CMake which doesn't influence the existing workflows.
I would be happy to learn you opinion regarding this proposal
|Steps To Reproduce||N/A|
|Tags||No tags attached.|
|Test case number||N/A|
|related to||0031087||verified||smoskvin||Open CASCADE||Configuration - make FreeType dependency optional|
|related to||0031401||new||kgv||Open CASCADE||Visualization - revise Toolkits dependency graph|
|related to||0023049||closed||bugmaster||Open CASCADE||Optimize packaging and dependencies of visualization libraries|
|related to||0031678||closed||bugmaster||Open CASCADE||Visualization - add option enabling hinting for textured fonts|
|parent of||0032286||closed||bugmaster||Community||Configuration, TKService - make Xlib dependency optional|
|related to||0032232||closed||bugmaster||Open CASCADE||Draw Harness - make Tk dependency optional|
|related to||0032308||closed||bugmaster||Open CASCADE||Configuration - make Xlib dependency optional|
Branch CR0032268 has been created by drazmyslovich.
Detailed log of new commits:
Author: Dzmitry Razmyslovich
Date: Tue Mar 30 13:49:47 2021 +0200
0032268: Introduce a MINIMAL_BUILD CMake option to be able to build a minimal algorithmic and data exchange set of libraries
If you would like adding an option excluding FreeType dependency - it is better proposing a dedicated patch introducing HAVE_FREETYPE option 0031087 for consistency with other 3rd-party components.
even thought the freetype dependency is the worst one, my proposal includes not only getting rid of this dependency, but also it concerns x11 and opengl dependencies for linux. And generally provides a single CMake flag to disable all miscellaneous stuff, which is usually not necessary for deploying OCC libraries for the usage in some applications.
Most probably, adding a CMake parameter for the location of MODULES file can even more simplify the building of OpenCASCADE library for such usage.
But you are right, that resolving 0031087 should be done in the first place.
I'm not quite understand in which case a dedicated MINIMAL_BUILD could be really useful - I guess only to simplify actions in (very unfriendly) cmake-gui tool.
Existing mechanisms already allow disabling entire MODULES or even manually defining the list of toolkits. See, for instance, building scripts in adm/scripts/cmake_gen.bat.
Will be there any difference with MINIMAL_BUILD option compared to BUILD_MODULE_Visualization=OFF, BUILD_MODULE_Draw=OFF?
Or you still want TKV3d/TKService libraries but without TKOpenGl?
Or the main concern is that TKService depends on Xlib?
In the latter case, I suppose that it would be useful to have a patch making Xlib dependency optional or/and moving these platform-dependent classes (Xw/WNT/Cocoa) to a dedicated library (to separate from Image / Graphic3d packages which do not depend on Win32 / Cocoa / Xlib in any way).
It might be necessary to do something like this anyway in case if we would like supporting natively Wayland.
Although excluding some Win32/Cocoa dependencies necessary to build WNT/Cocoa classes is close to useless on Windows / macOS systems where related frameworks are always available.
And when we talk about "minimal build", I would say it is debatable what is the minimal meaningful build of OCCT.
One may say that TKernel and TKMath pair is the already minimal things to have, why the other one would say that without TKOpenGl it will be useless :).
So that MINIMAL_BUILD in the current proposal looks more like a preference for a specific application rather than a widely adopted configuration.
Well, "minimal" is just a name, one can rename it to "deploy build" or something similar.
1. We use only 34 toolkits out of 61 build targets, which are generated by default by CMake and only disabling the modules is not enough (and not, I am not using cmake gui, I have my conan recipe to build OCCT and just specify CMake options per text). I really would like to be able to specify the list of toolkits I need. Why? Just to save time and resources when I need to deploy the need build of OpenCASCADE library. One can surely write a script which builds the required targets one by one. But you have already a mechanism for it - MODULES file, why just not giving an ability to use a custom one?
2. I would like to build these 34 toolkits without any non-obvious 3rd party dependencies including Xlib and OpenGL. Why? Because we do not use any functions of OpenCASCADE, which rely on these 3rd party libraries and at the same time we should always document all 3rd party dependencies. Surely, better modularization and separations of concerns should fix my problem in the way better form, rather just ifdefing some code.
All in all, this is just a proposal, which demonstrates what parts and how we build/use OpenCASCADE library. Maybe, you can derive from this proposal some additional useful options for CMake build (like custom modules file) or some ideas how to improve the separation of concerns between the modules, so that the dependencies to XLib and OpenGL can become optional in some cases.
I can definitely agree, that the proposed patch doesn't make much sense in the general case and can't be reintegrated in its current form. If you have any suggestions, how I can productively contribute on this matter, I stay open for you suggestions.
With the recent changes it is now possible:
- USE_FREETYPE - build TKService without FreeType 0031087.
- USE_TK - build Draw Harness without Tk 0032232 (Tcl is mandatory).
- USE_XLIB - build TKService and TKOpenGl without Xlib 0032308
(TKOpenGl is built with EGL using window-less configuration, so that it is still possible making off-screen images).
- USE_OPENGL and USE_GLES2 to build or not TKOpenGl and TKOpenGles 0032206.
So practically it is now possible disabling almost every 3rd-party library while building OCCT, save the libraries mandatory for core functionality of specific Module - like Tcl for Draw Harness, VTK for TKIVtk, etc. (in which case module is implicitly disabled by excluding related USE_ like USE_VTK=OFF or by disabling the module itself like BUILD_MODULE_Draw=OFF).
The further step could be allowing to specify exact list of Toolkits to customize build for narrow build - can be useful for projects using a small subset of OCCT functionality; for example, if project doesn't use STEP translator, but uses STL / glTF / IGES translators from Data Exchange module.
I guess that this can be provided as an option "BUILD_CHECKED_TOOLKITS" to filter out unchecked as alternative (or extension) to the list of Modules (in another OCCT-based repository we have a similar option "BUILD_CHECKED_MODULES" for listing Modules).
So that user will be able to check BUILD_TOOLKIT_TKViewerTest=OFF in GUI.
Although the list might look exhaustive and it might be enough defining a single variable BUILD_CHECKED_TOOLKITS considering the option for manual input - I suppose this will be more than enough for your use case.
Alternatively, it might be considered adding new meaningful configuration options like BUILD_STEP_IMPORT, BUILD_STEP_EXPORT, BUILD_IGES_IMPORT, etc.
This would let user less experienced in OCCT structure to deliberately select toolkits by their functionality rather than manually specifying toolkits based on prior knowledge of the structure.
Branch CR0032268_1 has been created by drazmyslovich.
Detailed log of new commits:
Author: Dzmitry Razmyslovich
Date: Thu Nov 25 17:46:56 2021 +0100
0032268: Fix build of the toolkits without freetype
I'm sorry for the delay with verifying the proposed solution. But now finally with the release of 7.6.0 I was able to verify it.
Thank you very much! It works as desired, it is possible to build OCCT without any 3rd party dependencies. There is still a small forgotten piece of code, which is not guarded with HAVE_FREETYPE define check. Please, review CR0032268_1 branch, which contains the changes to fix the build.
Also, I found out, that it is possible to BUILD_ADDITIONAL_TOOLKITS CMake variable to build only a specific set of libraries.
So, from my point of view, this feature is now fully available. Maybe, it would be nice to document it, that one can build a specific set of toolkits using CMake variable and no 3rd parties are necessary for particular cases.
Thank you once again.
Thank for update, Dima.
I've pushed the bugfix related to FreeType to reopened 0031087.
As for `BUILD_ADDITIONAL_TOOLKITS`, it is described in documentation as:
> Semicolon-separated individual toolkits to include into build process.
> If you want to build some particular libraries (toolkits) only,
> then you may uncheck all modules in the corresponding
> *BUILD_MODUE_\<MODULE\>* options and provide the list of necessary libraries here.
> Of course, all dependencies will be resolved automatically
and similar description within CMake variable description (shown by cmake-gui).
Do you have some suggestions how this description could be improved or worth to be mentioned elsewhere?
I would suggest to the following changes:
1. In the section of required 3rd party libraries mark all libraries as optional (or basically getting rid of the column) - https://dev.opencascade.org/doc/overview/html/index.html#intro_req_libs
2. In the section for building with CMake https://dev.opencascade.org/doc/overview/html/build_upgrade__building_occt.html#build_occt_win_cmake I would suggest to add one more section, which bridges the overview of the modules https://dev.opencascade.org/doc/overview/html/index.html#intro_overview and possibility to build one or another module. Yes, it is already described between the variables, but it is too far away and not obvious. I would here a section, which hints the developers, that it is possible to select the modules to build using the corresponding variables. And as a side note, I would propose to add, that it is even possible to build a set of individual toolkits using BUILD_ADDITIONAL_TOOLKITS variable
|2021-03-30 14:47||drazmyslovich||New Issue|
|2021-03-30 14:47||drazmyslovich||Assigned To||=> kgv|
|2021-03-30 14:50||git||Note Added: 0099871|
|2021-03-30 14:50||drazmyslovich||Status||new => resolved|
|2021-03-30 14:50||drazmyslovich||Steps to Reproduce Updated|
|2021-03-30 15:13||kgv||Category||OCCT:Coding => OCCT:Configuration|
|2021-03-30 15:13||kgv||Summary||A proposal for minimal build flag in CMake => Configuration, CMake - a proposal for minimal build flag in CMake|
|2021-03-30 15:13||kgv||Relationship added||related to 0031087|
|2021-03-30 15:15||kgv||Note Added: 0099875|
|2021-03-30 15:15||kgv||Note Edited: 0099875|
|2021-04-01 15:06||drazmyslovich||Note Added: 0099951|
|2021-04-01 15:27||kgv||Note Added: 0099955|
|2021-04-01 15:28||kgv||Note Edited: 0099955|
|2021-04-01 15:31||kgv||Note Edited: 0099955|
|2021-04-01 15:31||kgv||Note Edited: 0099955|
|2021-04-06 20:14||drazmyslovich||Note Added: 0100146|
|2021-04-06 20:45||kgv||Relationship added||related to 0031401|
|2021-04-06 20:50||kgv||Relationship added||related to 0023049|
|2021-04-06 21:18||kgv||Relationship added||parent of 0032286|
|2021-04-15 12:41||kgv||Relationship added||related to 0032232|
|2021-04-17 20:42||kgv||Relationship added||related to 0032308|
|2021-04-29 09:17||kgv||Note Added: 0100647|
|2021-04-29 09:17||kgv||Assigned To||kgv => drazmyslovich|
|2021-04-29 09:17||kgv||Status||resolved => assigned|
|2021-04-29 09:18||kgv||Note Edited: 0100647|
|2021-04-29 09:19||kgv||Note Edited: 0100647|
|2021-09-09 21:38||kgv||Target Version||7.6.0 => 7.7.0|
|2021-11-25 20:03||git||Note Added: 0105433|
|2021-11-25 20:08||drazmyslovich||Note Added: 0105434|
|2021-11-25 20:08||drazmyslovich||Assigned To||drazmyslovich => kgv|
|2021-11-25 20:08||drazmyslovich||Status||assigned => resolved|
|2021-11-25 20:43||kgv||Relationship added||child of 0031678|
|2021-11-25 20:43||kgv||Relationship replaced||related to 0031678|
|2021-11-25 20:58||kgv||Note Added: 0105442|
|2021-11-25 20:59||kgv||Test case number||=> N/A|
|2021-11-25 20:59||kgv||Assigned To||kgv => drazmyslovich|
|2021-11-25 20:59||kgv||Status||resolved => feedback|
|2021-11-25 21:38||drazmyslovich||Note Added: 0105443|
|2021-11-25 21:38||drazmyslovich||Assigned To||drazmyslovich => kgv|
|2021-11-25 21:38||drazmyslovich||Status||feedback => resolved|