<div dir="ltr"><div>Thanks for the reminder, Even. I haven't had time to properly look at the RFC before now and I might have missed some of the discussions so please excuse me if I'm repeating something that's already been discussed. 
I'm only concerned about the PROJ specifics of this RFC, so I've cut off the GDAL list from this thread to not generate too much noise.

</div><div><br></div><div>First of all, I think a PROJ-specific RFC is warranted. The contents should be largely the same, obviously without the very GDAL-oriented details such as affected files etc. I’d like the RFC to touch on the relation to [RFC-3](<a href="https://proj.org/en/9.5/community/rfc/rfc-3.html" target="_blank">https://proj.org/en/9.5/community/rfc/rfc-3.html</a>) as we are now talking about using cutting edge features of C23 and the purpose of RFC3 is to avoid that. I don’t think there’s a conflict as it seems you’ve managed to write the code in a backwards compatible manner. It does mean there’s a bunch of if-compiler-can-embed-files guards which would be great to get rid of once this functionality is mainstream. A rough plan for when that can be done would be great (as well as an accompanying GitHub issue so we remember to do it).</div><div><br></div><div>As for the actual embedded files. Is it only contained to proj.db and proj.ini in the case of PROJ? Or are there other files that potentially would be embedded? I suppose some of the smaller files like the ITRFxxxx files potentially could be useful. The RFC doesn’t mention contents from PROJ-data - I’m sure someone eventually will want to embed those as well, so maybe put in a sentence or two about that (and why it’s probably a bad idea).</div><div><br></div><div>Lastly, I think it would be good to touch on *when* you might want to embed resource files. I know this has been requested in the past but where it is actually useful I’m not sure. I’m probably not alone in that, so if the docs could include such an explanation it would be great. Could also be added to the RFC to make it a little bit easier to digest the thing before there’s a vote to adopt it.</div><div><br></div><div>/Kristian</div>

</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Oct 2024 at 18:12, 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">Hi,<br>
<br>
Proposed implementations are, as far as I can tell, feature complete now <br>
(including docs & CI):<br>
<br>
- GDAL: <a href="https://github.com/OSGeo/gdal/pull/10972" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/10972</a> . I propose that we <br>
target 3.11. We are probably too close to the feature freeze of 3.10 and <br>
would otherwise need to rush things, which feels unnecessary.<br>
<br>
- PROJ: <a href="https://github.com/OSGeo/PROJ/pull/4265" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ/pull/4265</a> . Embedding has also <br>
been extended to proj.ini , in addition to proj.db (both available in <br>
non-C23 or C23 modes)<br>
<br>
I've also updated the RFC text to reflect the current state of things.<br>
<br>
I let more time for people to review before submitting to vote, probably <br>
end of next week (as usual, tell if you need more time)<br>
<br>
Even<br>
<br>
Le 03/10/2024 à 19:30, Even Rouault via PROJ a écrit :<br>
> Hi,<br>
><br>
> I've now a PROJ branch with proj.db embedding working at <br>
> <a href="https://github.com/OSGeo/PROJ/pull/4265" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ/pull/4265</a>. And contrary to the current <br>
> wording of the RFC text, I've actually invested in making it work with <br>
> non-C23 compilers too (C23 mechanism used when available), by adapting <br>
> <a href="https://gitlab.com/jhamberg/cmake-examples/-/blob/master/cmake/FileEmbed.cmake" rel="noreferrer" target="_blank">https://gitlab.com/jhamberg/cmake-examples/-/blob/master/cmake/FileEmbed.cmake</a> <br>
> and optimizing it because its performance at generating a .c file from <br>
> a binary was not acceptable on multi-megabyte large files like <br>
> proj.db.  Non-C23 embedding works fine with older gcc, clang, MSVC. <br>
> The proj_db.c generation from proj.db runs in 8 seconds, and building <br>
> it with gcc in 18 seconds (looking at build times in CI, that seems to <br>
> be fast with MSVC too)<br>
><br>
> But I won't (probably) support non-C23 embedding for GDAL: that would <br>
> be too much complication w.r.t benefit. Only a "few" GDAL drivers need <br>
> resource files, whereas access to proj.db is a strong requirement.<br>
><br>
> Kurt, I had to modify the memOpen() and the memvfs_init() functions of <br>
> the <a href="https://www.sqlite.org/src/doc/tip/ext/misc/memvfs.c" rel="noreferrer" target="_blank">https://www.sqlite.org/src/doc/tip/ext/misc/memvfs.c</a> (I did other <br>
> changes in memvfs_init() to avoid making it the default VFS, and <br>
> registering it per db-connection to avoid a global registration), <br>
> otherwise some complex SQL requests that require creating a temporary <br>
> file wouldn't work, such as the ones of 'bin/projinfo --list-crs' or <br>
> 'bin/cct "this is a bogus CRS meant to trigger a syntax error in <br>
> proj_create"'  (with sqlite 3.46 of fedora:rawhide). Is it something <br>
> you ran into? Cf the changes in memvfs.c in <br>
> <a href="https://github.com/rouault/PROJ/commit/e7fcf162f6968c48587836f537b506708112e7d4" rel="noreferrer" target="_blank">https://github.com/rouault/PROJ/commit/e7fcf162f6968c48587836f537b506708112e7d4</a><br>
><br>
> With those changes, ctest pass<br>
><br>
> Even<br>
><br>
><br>
> <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
> My software is free, but my time generally not.<br>
><br>
> _______________________________________________<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>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<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>