Presumably that should come as a separate PR which builds on this one? On Sun, 19 Apr 2020, 11:26 Adam Retter, <adam.ret...@googlemail.com> wrote:
> Shouldn't be too bad. Depends on what packages are prebuilt and available > - I can take a look later > > On Sun, 19 Apr 2020, 04:43 Alex Remily, <alex.rem...@gmail.com> wrote: > >> Thanks Adam. Very much appreciated. How much effort would it be to do >> the >> same for OpenSSL 1.1.x? >> >> On Sat, Apr 18, 2020 at 11:41 AM Adam Retter >> <adam.ret...@googlemail.com.invalid> wrote: >> >> > As promised, I added support for further environments to Travis - >> > https://github.com/apache/commons-crypto/pull/96 >> > >> > On Mon, 13 Apr 2020 at 16:35, Alex Remily <alex.rem...@gmail.com> >> wrote: >> > > >> > > I don't know whether it would help the build manager with the release >> > > process, but I think it would be a good idea to update the build >> matrix >> > > regardless. I made an attempt a while ago to add coverage for more >> > > environments, but ultimately I wasn't successful. I don't recall if >> the >> > > limitations were Travis's or my own, but I would certainly welcome >> > someone >> > > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 >> APIs in >> > > whatever Windows, Mac, Linux and Arm64 environments Travis supports. >> My >> > > $0.02. >> > > >> > > Alex >> > > >> > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter >> > > <adam.ret...@googlemail.com.invalid> wrote: >> > > >> > > > Travis now offer Arm64 and Mac. I could setup a job to build >> binaries >> > on >> > > > Travis and keep a copy either on every commit or when a tag is >> created. >> > > > Would that be helpful? >> > > > >> > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, <garydgreg...@gmail.com> >> > wrote: >> > > > >> > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily < >> alex.rem...@gmail.com> >> > > > wrote: >> > > > > >> > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm >> happy >> > to >> > > > > > provide whichever of those is required. It seems that Geoff can >> > do the >> > > > > > arm64 build. Do we even bother supporting 32 bit architectures >> at >> > this >> > > > > > point? >> > > > > > >> > > > > >> > > > > Unfortunately, we cannot just pick up bits from folks here and >> > there. It >> > > > > all has to be buildable from Maven by the release manager in >> order to >> > > > > generate the file signatures properly. >> > > > > >> > > > > Based on what I see in the docs, it looks like this is buildable >> > using >> > > > > cross-compilation with MinGW on Windows. Not sure about the Mac >> stuff >> > > > yet. >> > > > > >> > > > > I'm not sure what the use-case is for 32-bit at this point. >> > > > > >> > > > > Gary >> > > > > >> > > > > >> > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin < >> van...@apache.org> >> > > > > wrote: >> > > > > > >> > > > > > > Hi Gary, >> > > > > > > >> > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory < >> > garydgreg...@gmail.com >> > > > > >> > > > > > > wrote: >> > > > > > > > > The 1.0 release on maven central only included linux32 and >> > > > linux64 >> > > > > > > native >> > > > > > > > > libs, even though the Makefile supports many more targets >> > > > > > > > > >> > > > > > > > >> > > > > > > > Please see the snapshot builds which now include more: >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > >> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT >> > > > > > > >> > > > > > > Here's the native stuff in your snapshot jar: >> > > > > > > >> > > > > > > $ jar tf commons-crypto-1.1.0-20200411.124009-5.jar | grep >> > > > > > > nativeorg/apache/commons/crypto/native/ >> > > > > > > org/apache/commons/crypto/native/Linux/ >> > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ >> > > > > > > >> > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so >> > > > > > > >> > > > > > > Here's the 1.0 release: >> > > > > > > >> > > > > > > $ jar tf >> > > > > > > >> > > > > > >> > > > > >> > > > >> > >> ~/.ivy2/cache/org.apache.commons/commons-crypto/jars/commons-crypto-1.0.0.jar >> > > > > > > | grep native >> > > > > > > org/apache/commons/crypto/native/ >> > > > > > > org/apache/commons/crypto/native/Linux/ >> > > > > > > org/apache/commons/crypto/native/Linux/x86/ >> > > > > > > org/apache/commons/crypto/native/Linux/x86_64/ >> > > > > > > org/apache/commons/crypto/native/Mac/ >> > > > > > > org/apache/commons/crypto/native/Mac/x86_64/ >> > > > > > > org/apache/commons/crypto/native/Windows/ >> > > > > > > org/apache/commons/crypto/native/Windows/x86/ >> > > > > > > org/apache/commons/crypto/native/Windows/x86_64/ >> > > > > > > >> org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so >> > > > > > > >> > org/apache/commons/crypto/native/Linux/x86_64/libcommons-crypto.so >> > > > > > > >> > org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib >> > > > > > > >> org/apache/commons/crypto/native/Windows/x86/commons-crypto.dll >> > > > > > > >> > org/apache/commons/crypto/native/Windows/x86_64/commons-crypto.dll >> > > > > > > >> > > > > > > That's the only thing that worries me: finding someone who can >> > build >> > > > > > > all those extra native libraries. I tend to agree that linux64 >> > is the >> > > > > > > most important one, but it would be technically a regression >> > from 1.0 >> > > > > > > to skip the others. >> > > > > > > >> > > > > > > That being said, if we can't solve that, I think it's better >> to >> > > > > > > release something rather than nothing. >> > > > > > > >> > > > > > > >> > --------------------------------------------------------------------- >> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > >> > >> > >> > -- >> > Adam Retter >> > >> > skype: adam.retter >> > tweet: adamretter >> > http://www.adamretter.org.uk >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >
