[postgis-devel] Making SFCGAL mandatory

[Hugo Mercier]

Hi,

As a co-author of SFCGAL, I have to answer to some concerns :)

I cannot deny we had hard times maintaining SFCGAL in the past. We
initially completely underestimated the efforts needed to compile and
package it. And we unfortunately then lacked time and resources to work
on it.

Just to answer to some raised points here:

> It's deep reliance on CGAL which itself doesn't seem to care about
> breaking people's stuff scares me.

It is not entirely CGAL's fault. In first versions, SFCGAL relied on
undocumented CGAL functions that were about to be included in the
following versions (mesh corefinement functions). But we did not make
the transition and SFCGAL is still shipped with some parts of CGAL that
are not part of the official distribution.

CGAL developers now react quickly to some compilation problems on
SFCGAL's github and they have even recently prepared it for the coming
of the next version of CGAL (4.14) to make sure it compiles.

I have released a 1.3.6 version two days ago that fixes some packaging
problems.

I do not have a strong opinion about compilation flags and which default
to retain.
However I think Regina raised an important point:

> The only unfortunate thing I see with it, is unlike raster which is a
> completely separate lib file, it is tangled in with the postgis lib
> when built.
> I suspect we can't fix this that the whole backend switch thing
> requires it to be that way.  So that would make it much harder for
> packagers to have a version with and without SFCGAL.

If I understand correctly, it would help to have something like a
postgis_sfcgal.so as an optional library that brings SFCGAL
functionalities rather than having only one postgis.so with or without
SFCGAL in it ?

I am pretty sure there is a way to make the backend switch more
"dynamic" and work with a separate library, but I would have to dig a
bit deeper.