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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
