Re: Optional rust library as a dependency of the Zarr driver
Even Rouault via gdal-dev <[email protected]> Fri, 12 Jun 2026 02:34:02 +0200
| Newsgroups | gmane.comp.gis.gdal.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============8658554185948079346==
Content-Type: multipart/alternative;
boundary="------------zGKgVZVZf5wYH9ZGSFBLUKuJ"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------zGKgVZVZf5wYH9ZGSFBLUKuJ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
> Yes, I know there might be checksums, but I think it's still a problem.
As you've noticed by carefully reviewing the PR 😜 , it uses sha1sum to
identify tags
> I think a good example is librsvg. It's a library, written significantl
> in rust, but programs that use it just look for a .h and link against
> it. They aren't forced to act like it's all special because it used
> rust.
As you've noticed, my PR offers that possibility if someone packages
cpcodec and installs pcodec.h and libpcodec.so
>
> Is pcodec packaged in Debian or any place else?
Not that I'm aware of
> Deoes gdal have a prior history of dealing with dependencies that should
> be packaged but aren't?
yes and no. We have a few vendored ones
>
> I wonder if the plugin system is the answer here, to say that anything
> with troublesome (not packaged and checkable with cmake without special
> help) dependencies should be a plugin maintained in a separate repo.
The Zarr driver itself can be built as a plugin. But a plugin of a
plugin, that's unknown territory
Anyway if you or anyone else doesn't like it, GDAL_USE_PCODEC=NO will be
your friend, and/or not having git or cargo in your build env.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
--------------zGKgVZVZf5wYH9ZGSFBLUKuJ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<blockquote type="cite" cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">
Yes, I know there might be checksums, but I think it's still a problem.</pre>
</blockquote>
As you've noticed by carefully reviewing the PRÂ <span
class="JCzEY tNxQIb"
style="transform: translate3d(0px, 0px, 0px);"><span
class="CSkcDe">😜</span></span> , it uses sha1sum to identify
tags
<blockquote type="cite" cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">
I think a good example is librsvg. It's a library, written significantl
in rust, but programs that use it just look for a .h and link against
it. They aren't forced to act like it's all special because it used
rust.</pre>
</blockquote>
As you've noticed, my PR offers that possibility if someone packages
cpcodec and installs pcodec.h and libpcodec.so
<blockquote type="cite" cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">
Is pcodec packaged in Debian or any place else? </pre>
</blockquote>
Not that I'm aware of
<blockquote type="cite" cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">
Deoes gdal have a prior history of dealing with dependencies that should
be packaged but aren't?</pre>
</blockquote>
yes and no. We have a few vendored ones
<blockquote type="cite" cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">
I wonder if the plugin system is the answer here, to say that anything
with troublesome (not packaged and checkable with cmake without special
help) dependencies should be a plugin maintained in a separate repo.</pre>
</blockquote>
<p>The Zarr driver itself can be built as a plugin. But a plugin of
a plugin, that's unknown territory</p>
<p>Anyway if you or anyone else doesn't like it, GDAL_USE_PCODEC=NO
will be your friend, and/or not having git or cargo in your build
env.</p>
<p>Even</p>
<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>
--------------zGKgVZVZf5wYH9ZGSFBLUKuJ--
--===============8658554185948079346==
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
--===============8658554185948079346==--