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

[Kurt Schwehr]

So excited for this feature. We have custom code that does stuff like this.

e.g.

+    // BEGIN GOOGLE MODIFICATION
+    int flags = SQLITE_OPEN_READONLY | SQLITE_OPEN_NOMUTEX;
     if (path.empty()) {
-        path.resize(2048);
-        const bool found =
-            pj_find_file(pjCtxt(), "proj.db", &path[0], path.size() - 1)
!= 0;
-        path.resize(strlen(path.c_str()));
-        if (!found) {
-            throw FactoryException("Cannot find proj.db");
-        }
+        static const FileToc *toc = [] {
+          // Enable the memvfs extension.
+          const int init_code = sqlite3_memvfs_init(nullptr, nullptr,
nullptr);
+          if (init_code != SQLITE_OK_LOAD_PERMANENTLY) {
+            throw FactoryException(
+                absl::StrCat("Can't initialize memvfs, with code ",
init_code));
+          }
+          // Re-register 'unix' as default filesystem. MemVFS can be used
+          // through URL parameters, or by passing as the fourth argument
to
+          // sqlite3_open_v2().
+          const int register_code =
+              sqlite3_vfs_register(sqlite3_vfs_find("unix"), /*makeDflt
=*/1);
+          if (register_code != SQLITE_OK) {
+            throw FactoryException(absl::StrCat(
+                "Can't re-register the default VFS, with code ",
init_code));
+          }
+          return proj_db_create();
+        }();
+        // Load the database from a cc_embed_file, using the memvfs
+        // extension of sqlite.
+        path =
absl::StrFormat("file:/proj?ptr=0x%x&sz=%d&max=%d&vfs=memvfs",
+                               reinterpret_cast<uintptr_t>(toc[0].data),
+                               toc[0].size, toc[0].size);
+        flags |= SQLITE_OPEN_URI;
     }
+    // END GOOGLE MODIFICATION

On Tue, Oct 1, 2024 at 10:28 AM Even Rouault via PROJ <proj at lists.osgeo.org>
wrote:

> Greg,
>
> What's unclear is to what extent things continue to be ok on compilers
> not supporting C23, and if they are, if those systems start to be second
> class.    My overall feeling is that it is vastly too early to be
> depending on C23.
>
> The RFC is clear enough this is an optional feature ("C23 is not required
> if EMBED_RESOURCE_FILES is not enabled"). If you need it, you will need a
> C23 compiler, which there is already one available (clang 19), and another
> one in a near future (gcc 15).
>
> C23 is only used to build the .c files where resources are embedded.
>
> If you don't need that new feature, you can use the current minimum build
> requirements of GDAL/PROJ.
>
> For once that GDAL/PROJ can use shiny new stuff, let's enjoy :-)
>
> But maybe c23 is c2x, and it's been supported in gcc for 6 years.
>
> No way a gcc from 6 years ago can support #embed: support has literally
> landed in GCC master 2 weeks ago.
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241002/feb0ec55/attachment.htm>