> If the only concern is the file signatures, I'm almost sure that the
> maven build will pick up native libraries you drop in some directory
> and include them in the jar, regardless of whether they're for the
> current architecture. Then you'd get the jar with all native libraries
> and the right signature.

Yes, I've seen the same thing when producing a Jar of commons-crypto
with both x86 and AArch64 native libraries.  Just create the proper
dirs for the final build and sign.

With travis, there is a way to save off the artifacts:
https://docs.travis-ci.com/user/uploading-artifacts/.  It may be
something to consider to auto-generate releases as Travis does support
Linux on arm, and x86 (though only ubuntu which should be fine for
building and linking).

-Geoff


On Sun, Apr 12, 2020 at 10:03 PM Marcelo Vanzin <van...@gmail.com> wrote:
>
> On Sun, Apr 12, 2020 at 6:13 PM Gary Gregory <garydgreg...@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.
>
> If the only concern is the file signatures, I'm almost sure that the
> maven build will pick up native libraries you drop in some directory
> and include them in the jar, regardless of whether they're for the
> current architecture. Then you'd get the jar with all native libraries
> and the right signature.
>
> $ mkdir -p target/classes/org/apache/commons/crypto/native/Linux/x86
> $ touch !$/fake.so
> touch target/classes/org/apache/commons/crypto/native/Linux/x86/fake.so
> $ mvn package
> $ jar tf target/commons-crypto-1.1.0-SNAPSHOT.jar  | grep fake.so
> org/apache/commons/crypto/native/Linux/x86/fake.so
>
> Frankly, given you need things built on different platforms, that
> seems like the easiest way to get a jar with multiple native libraries
> - setting up cross-compilers would be kind of a pain.
>
> Now if the requirement is that the release manager needs to build
> everything himself, then that makes it a little more complicated.
>
> --
> Marcelo Vanzin
> van...@gmail.com
> "Life's too short to drink cheap beer"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to