пт, 31 мая 2024 г. в 01:16, William Lallemand <wlallem...@irq6.net>:
> On Thu, May 30, 2024 at 10:31:14PM +0200, Ilia Shipitsin wrote: > > Subject: [PATCH 2/3] CI: build-ssl.sh: allow to choose certain QuicTLS > commit hash > > --- > > scripts/build-ssl.sh | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/scripts/build-ssl.sh b/scripts/build-ssl.sh > > index f1a6f8a86..15d2c242f 100755 > > --- a/scripts/build-ssl.sh > > +++ b/scripts/build-ssl.sh > > @@ -149,6 +149,12 @@ build_aws_lc () { > > download_quictls () { > > if [ ! -d "${BUILDSSL_TMPDIR}/quictls" ]; then > > git clone --depth=1 https://github.com/quictls/openssl > ${BUILDSSL_TMPDIR}/quictls > > + if [ -n "${QUICTLS_COMMIT}" ]; then > > + ( > > + cd ${BUILDSSL_TMPDIR}/quictls > > + git checkout ${QUICTLS_COMMIT} > > + ) > > + fi > > else > > ( > > cd ${BUILDSSL_TMPDIR}/quictls > > Hello, > > Could you use the same method as we've done in WolfSSL instead? So we can > specify a fixed version or a commit with the > same variable. Since quictls does have multiple branches and releases that > would be cleaner ! > I thought about it. such approach has drawbacks: 1) we'll have to keep an eye on QuicTLS whether new release is emitted (which I'd like to avoid) 2) if we want to keep current approach QUICTLS=yes and introduce new behaviour like QUICTLS_HASH=nnn, it will be similar level of complexity indeed, if we decide to drop QUICTLS=yes in favour of commit hash as the only method, it will be a simplification > > Thanks, > > -- > William Lallemand >