<div dir="ltr">So excited for this feature. We have custom code that does stuff like this.<div><br></div><div>e.g.</div><div><br></div><div>+ // BEGIN GOOGLE MODIFICATION<br>+ int flags = SQLITE_OPEN_READONLY | SQLITE_OPEN_NOMUTEX;<br> if (path.empty()) {<br>- path.resize(2048);<br>- const bool found =<br>- pj_find_file(pjCtxt(), "proj.db", &path[0], path.size() - 1) != 0;<br>- path.resize(strlen(path.c_str()));<br>- if (!found) {<br>- throw FactoryException("Cannot find proj.db");<br>- }<br>+ static const FileToc *toc = [] {<br>+ // Enable the memvfs extension.<br>+ const int init_code = sqlite3_memvfs_init(nullptr, nullptr, nullptr);<br>+ if (init_code != SQLITE_OK_LOAD_PERMANENTLY) {<br>+ throw FactoryException(<br>+ absl::StrCat("Can't initialize memvfs, with code ", init_code));<br>+ }<br>+ // Re-register 'unix' as default filesystem. MemVFS can be used<br>+ // through URL parameters, or by passing as the fourth argument to<br>+ // sqlite3_open_v2().<br>+ const int register_code =<br>+ sqlite3_vfs_register(sqlite3_vfs_find("unix"), /*makeDflt =*/1);<br>+ if (register_code != SQLITE_OK) {<br>+ throw FactoryException(absl::StrCat(<br>+ "Can't re-register the default VFS, with code ", init_code));<br>+ }<br>+ return proj_db_create();<br>+ }();<br>+ // Load the database from a cc_embed_file, using the memvfs<br>+ // extension of sqlite.<br>+ path = absl::StrFormat("file:/proj?ptr=0x%x&sz=%d&max=%d&vfs=memvfs",<br>+ reinterpret_cast<uintptr_t>(toc[0].data),<br>+ toc[0].size, toc[0].size);<br>+ flags |= SQLITE_OPEN_URI;<br> }<br>+ // END GOOGLE MODIFICATION<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 1, 2024 at 10:28 AM Even Rouault via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
Greg,
<blockquote type="cite">
<pre>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.</pre>
</blockquote>
<p>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).</p>
<p>C23 is only used to build the .c files where resources are
embedded.<br>
</p>
<p>If you don't need that new feature, you can use the current
minimum build requirements of GDAL/PROJ.</p>
<p>For once that GDAL/PROJ can use shiny new stuff, let's enjoy :-)<br>
</p>
<blockquote type="cite">
<pre>But maybe c23 is c2x, and it's been supported in gcc for 6 years.</pre>
</blockquote>
<p>No way a gcc from 6 years ago can support #embed: support has
literally landed in GCC master 2 weeks ago.</p>
<span style="white-space:pre-wrap">
</span>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>