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

[Even Rouault]

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.