пт, 31 мая 2024 г. в 01:16, William Lallemand <[email protected]>:
> 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
>
