Now that we require CMake>=3.1, we can forget a lot of old CMake policies.
`CMP0053` `OLD` behavior is still needed, because of a bug in Qt5 CMake files, but it will
not be set with CMake>=3.10. Let's assume that a recent CMake version means
a recent Qt5 version.
- The Debian package uses `-DCGAL_ENABLE_PRECONFIG=OFF` and
`WITH_GMPXX=ON`. In that setup, GMPXX must in the "essential" 3rd
party libraries.
- The CGAL_Core library must be linked with its
dependencies (compilation error with `-zdefs`).
- Now even CGAL_Core has one.
- The `${cgal_lib}_FOUND` are now set in those modules, after having chec
- For self-consistency, `Use_CGAL_Qt5_headers` is included by
`CGAL_SetupCGAL_Qt5Dependencies`.
Because of bug in gcc, even if the C++11 `thread_local` keyword can be
used, it cannot be used for the TLS static member of the class template
`MemoryPool<T>`. That triggers a bug in gcc (tested with g++ 6.3.1):
```
.../include/CGAL/CORE/MemoryPool.h:113:25: error: redefinition of 'bool __tls_guard'
MemoryPool<T, nObjects> MemoryPool<T, nObjects>::memPool;
^~~~~~~~~~~~~~~~~~~~~~~
.../include/CGAL/CORE/MemoryPool.h:113:25: note: 'bool __tls_guard' previously declared here
.../include/CGAL/CORE/MemoryPool.h:113: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/cc4xCWuR.out file, please attach this to your bugreport.
```
The bug seems to be from g++ >= 5:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948
The commit 6c77740485 was not complete:
> CORE MemoryPool<T> has to be destroyed last
>
> If Boost implementation of thread local storage is used, the order of
> destructors is reversed, compared to C++11 `static thread_local`. The
> solution for CORE `MemoryPool<T>` is to make the static variable a
> static member of the class, and initialize the pointer only inside the
> function. That ensures that the destructor will be called after the
> destructor of local static variables.
Actually the explanation about the reverse order is not right, and even
with C++ `thread_local`, we have to ensure that the static data member
of `MemoryPool<T>` is created before any other CORE static variable.
This commit is a followup of the commit
6c7774048521d2779d1657871f476624a46d220b: even in C++11, the `memPool`
variable becomes a thread-local data member, instead of a thread-local
variable at function scope.
Fix#1844.