Build CGAL 5.6.1 to shared library

[Akira-Tsunami]

I'm new to CGAL. I want to incorporate the library part of CGAL to the my custom plugin of Unreal Engine. At first, I tried to use it as headers-only library; however, CGAL has dependency on boost and boost has many naming violation with the macros/functions/symbols of Unreal itself when compiling, so it didn't work.
So now I'm trying to build CGAL 5.6.1 to shared library (.dll in Windows), but I can't figure out how to do like this. I tried to set the variable like BUILD_SHARED_LIBS manifested in documentation. But it still didn't work. When I configured out and generated, the project just produced another identical headers-only library. And I browsed the content of cmake-related files that seems there are very few hints about this variable BUILD_SHARED_LIBS (sorry I have no much experience with CMake). And I found the default is headers-only since CGAL 5.0.
So my question is there option to build CGAL 5.6.1 to shared library? If yes, how to enable it? Or I have to resort to the older version?

[afabri]

Hello, this would not help you. The built library contained only a few global non-template functions and some global variables. Whart you have to do instead is build a shared library where inside you use CGAL, but the exported interfaces are CGAL-free,

Can you shatre a minimal project on github which exposes the problem you experience.,We then could have a look.

[Akira-Tsunami]

Hi, thank you very much for your reply! With your hints, after some struggling, I have found a solution to temporally workaround current problem. Sorry I feel a bit difficult to share my project because my project is Unreal-Based and it requires Unreal Engine Environment. But I will try my best to explain in details the problem I encountered.

First of all, maybe I should describe briefly how Unreal Build System works. Unreal C++ files are structured with "Modules", and each module corresponds to a shared library file (if it's not headers-only) and its header files. A module can refer to other modules. They can be categorized as either Unreal Module or External Module (i.e. Third Party). Unreal Modules are typically stuff containing many c++ files with features of Unreal itself (and also should be structured by the standard of Unreal), like RTTI; and external module can be native c++ files but should be pre-compiled.

In my case, I want to design and implement a custom module called A, and make use of another module B incorporating the CGAL libraries. Of course module B is external module as I firstly designed it . But when my module A refer to module B, by including the the headers of CGAL from B in headers or source files from A , like "CGAL/mesh_segmentation.h", many miscellaneous errors are reported like these:

And after my inspection of the many source code file where errors occur, I found the origin of errors are exactly same, like the file
"boost/core/pointer_traits.hpp" in line 128:

There are many template functions named with "check" in boost, and when I includes "mesh_segmentation.h" in one of files in my module A, these boost headers are also included in it. But as I mentioned before, module A as an Unreal Module have many features from Unreal, and "check" is just macro function that do assertion in the context of Unreal. So when "check" is specified in Unreal Module, it will be dealt with as the macro function automatically by Unreal Build System.

I can't modify the Unreal Build System and its features. So at first I tried to directly build CGAL to shared library and it's really frustrating for me because this attempt didn't work. But with your hints, I have one solution to this problem:

I can design and implement an adapter layer in module B (now module B is an unreal module), using #undef check to disable "check" macro in adapter 's source file like

****.h

****.cpp

In this case, FMeshSegmenter is like an adapter.

Module B now is literally unreal module consisting of CGAL and its adapters. Though it's not a perfect solution, because it has a side effect that I can't use "check" macro assertion in this cpp file. But now, I can take advantages of this adapter interface in module A, and this adapter interface can be also called in other modules.