|Anonymous | Login||2021-05-16 08:35 MSK|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0032268||Community||[OCCT] OCCT:Configuration||public||2021-03-30 14:47||2021-04-29 09:19|
|Product Version||[OCCT] 7.6.0*|
|Target Version||[OCCT] 7.6.0*||Fixed in Version|
|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|
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
edited on: 2021-03-30 15:15
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.
edited on: 2021-04-01 15:31
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.
edited on: 2021-04-29 09:19
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.
|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||View Revisions|
|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||View Revisions|
|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||View Revisions|
|2021-04-01 15:31||kgv||Note Edited: 0099955||View Revisions|
|2021-04-01 15:31||kgv||Note Edited: 0099955||View Revisions|
|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||View Revisions|
|2021-04-29 09:19||kgv||Note Edited: 0100647||View Revisions|
|Copyright © 2000 - 2021 MantisBT Team|