[postgis-devel] Making SFCGAL mandatory
Greg Troxel
gdt at lexort.com
Mon Nov 12 07:40:34 PST 2018
Daniel Baston <dbaston at gmail.com> writes:
[replying to thread and picking your message as most recent]
> Well, the current behavior is to build with SFCGAL if it's found, and
> silently build without it if it's not. It might be advantageous to set a
> rigid default (either SFCGAL on or off; I'd lean towards off) that can be
> overridden with `--with-sfcgal` or `--without-sfcgal`.
Bas makes two good points that I'd like to concur with:
sfcgal is not even in pkgsrc at all. I don't even know what it does.
(Don't tell me; I can look it up - the point is that it isn't
important enough for me to have absorbed it over the years.) That to
me is a clue that it's not a core component. If it doesn't have a
robust upstream with regular maintenance releases, it shouldn't be
depended on.
Indeed, packagers will just add --disable for dependencies that break
if the main package is still useful.
And I concur with my earlier self that enabling things automatically is
on balance not helpful. Default on or off, and fail if on and not found.
So I concur with Dan to have a rigid default, and I think it ought to be
--without.
Finally, for things that can be built separately, it would be really
nice -- even if they are in the postgis source tree and release
tarball -- to have them be separate so you can
unpack postgis and build and install it (without the extra)
without the above build tree still around, unpack postgis and build
the extra thing against the installed postgis and install it
That makes it easy to have a postgis-sfcgal split package. (I realize
some packaging systems can build package and split out files, but that
requires all the dependencies to be working ok and actually built at
build time, which 1) isn't good for users building from source and 2)
doesn't work if dependencies are not entirely reliable.)
More information about the postgis-devel
mailing list