[gdal-dev] [PROJ] RFC 102: Embedding resource files into libgdal (and PROJ)

Kurt Schwehr schwehr at gmail.com
Thu Oct 3 11:27:52 PDT 2024


For my weird google production setup: I haven't heard of any bugs along
those lines. I only build cs2cs and gie for running tests and users have no
access to any of the proj binaries in production. I don't think folks do
much with sqlite (most db usage are things like Spanner or FireBase) and
most proj usage is pretty boring.

If they need them, they get them through debian on their desktops or
whatever cloud container they might use if they are allowed to do that, but
not in the normal production environment.

On Thu, Oct 3, 2024 at 10:30 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi,
>
> I've now a PROJ branch with proj.db embedding working at
> https://github.com/OSGeo/PROJ/pull/4265. And contrary to the current
> wording of the RFC text, I've actually invested in making it work with
> non-C23 compilers too (C23 mechanism used when available), by adapting
>
> https://gitlab.com/jhamberg/cmake-examples/-/blob/master/cmake/FileEmbed.cmake
> and optimizing it because its performance at generating a .c file from a
> binary was not acceptable on multi-megabyte large files like proj.db.
> Non-C23 embedding works fine with older gcc, clang, MSVC. The proj_db.c
> generation from proj.db runs in 8 seconds, and building it with gcc in
> 18 seconds (looking at build times in CI, that seems to be fast with
> MSVC too)
>
> But I won't (probably) support non-C23 embedding for GDAL: that would be
> too much complication w.r.t benefit. Only a "few" GDAL drivers need
> resource files, whereas access to proj.db is a strong requirement.
>
> Kurt, I had to modify the memOpen() and the memvfs_init() functions of
> the https://www.sqlite.org/src/doc/tip/ext/misc/memvfs.c (I did other
> changes in memvfs_init() to avoid making it the default VFS, and
> registering it per db-connection to avoid a global registration),
> otherwise some complex SQL requests that require creating a temporary
> file wouldn't work, such as the ones of 'bin/projinfo --list-crs' or
> 'bin/cct "this is a bogus CRS meant to trigger a syntax error in
> proj_create"'  (with sqlite 3.46 of fedora:rawhide). Is it something you
> ran into? Cf the changes in memvfs.c in
>
> https://github.com/rouault/PROJ/commit/e7fcf162f6968c48587836f537b506708112e7d4
>
> With those changes, ctest pass
>
> Even
>
>
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241003/6900bc14/attachment.htm>


More information about the gdal-dev mailing list