Re: [PROJ] RFC 102: Embedding resource files into libgdal (and PROJ)

Even Rouault via gdal-dev <[email protected]> Tue, 1 Oct 2024 19:28:28 +0200
Newsgroups	gmane.comp.gis.gdal.devel,gmane.comp.gis.proj-4.devel
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--===============3607611178223219362==
Content-Type: multipart/alternative;
 boundary="------------CeUGETkqqG91GDgb83IAuGUW"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------CeUGETkqqG91GDgb83IAuGUW
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

--------------CeUGETkqqG91GDgb83IAuGUW
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Greg,
    <blockquote type="cite" cite="mid:[email protected]">
      <pre class="moz-quote-pre" wrap="">
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" cite="mid:[email protected]">
      <pre class="moz-quote-pre" wrap="">

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 class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>

--------------CeUGETkqqG91GDgb83IAuGUW--

--===============3607611178223219362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

--===============3607611178223219362==--