chore: Bump curl and libz-sys

[brainstorm]

See rust-lang/libz-sys#63 for context.

[pmarks]

@brainstorm are you sure that's actually giving you zlib-ng? According to this PR, you also need to set default-features = false: rust-lang/libz-sys@754ca14#diff-80398c5faae3c069e4e6aa2ed11b28c0R45

[brainstorm]

This will take a little bit more time to validate/merge since there's some assert/assumptions from htslib's upstream, see context here: rust-lang/libz-sys#63 (comment)

Not much time right now to dive into that, unfortunately (as much as I would love to). Anybody else, please feel free to steal my thunder here ;)

[ghuls]

This is fixed in the development version of HTSlib (and should be in 1.13, when it is released):
samtools/htslib#1258
samtools/htslib#1257

[brainstorm]

@johanneskoester Would it be ok to sync hts-sys to current htslib HEAD or closest release that fixes this?

[brainstorm]

As hinted and discussed in issue #329, build.rs from hts-sys will need some enhancements so that it doesn't break across releases.

Jumping from an upstream htslib release tag should ideally be just pulling the submodule commit and perhaps adapt (htslib) API breaking changes, which hopefully shouldn't be many, but I'm not sure what's the best way to keep build.rs from getting in the way?

For context, the build.rs refactor that @pmarks did relatively recently (partly bypassing @htslib build system) helped with bad stale file issues that broke builds. On the other hand, upstream devs like @jmarshall point out that we should just use the current configure.ac to have all this well integrated. I've seen both approaches break in different ways, so that's why I'm pointing it out before keeping on hacking it together until it works?

[johanneskoester]

As hinted and discussed in issue #329, build.rs from hts-sys will need some enhancements so that it doesn't break across releases.

Jumping from an upstream htslib release tag should ideally be just pulling the submodule commit and perhaps adapt (htslib) API breaking changes, which hopefully shouldn't be many, but I'm not sure what's the best way to keep build.rs from getting in the way?

For context, the build.rs refactor that @pmarks did relatively recently (partly bypassing @htslib build system) helped with bad stale file issues that broke builds. On the other hand, upstream devs like @jmarshall point out that we should just use the current configure.ac to have all this well integrated. I've seen both approaches break in different ways, so that's why I'm pointing it out before keeping on hacking it together until it works?

I agree. I would like to not replicate the htslib build in build.rs, but rather just use their system as much as possible. It just requires too much maintenance as it is now. I am just not enough into this to fix it, so please go ahead! Any simplification or improvement would be great!

[pmarks]

The tricky thing to get right is to have the htslib build use all the same libraries as appear elsewhere in the Rust build. That's what is happening when we take e.g. $DEP_BZIP2_ROOT and pass it to the cc::Build.include() function here. Presumably that can be achieved by passing these paths to htslib/configure. On Mac at least, autoconf isn't available by default, so going that route makes the build less likely to 'just work', which is why I went this route.

[pmarks]

But I certainly agree that it's a maintenance burden to keep up with changes to htslib & reusing their build system reduces that burden.

[jmarshall]

On the other hand, upstream devs like @jmarshall point out that we should just use the current configure.ac to have all this well integrated.

Please do not @-mention me on things that I have no interest in.

Do not ascribe to me opinions that I have not stated. I said that build.rs should follow htslib's configure.ac more carefully, not that it necessarily should use configure directly instead.

For the list of source filenames problem, you might look at how pysam does this and at make -C htslib print-config (though this would be more accurate if you did use configure).

[pmarks]

For the list of source filenames problem, you might look at how pysam does this and at make -C htslib print-config (though this would be more accurate if you did use configure).

oh cool, that's a great option, I'll see if that's feasible.