ATM we only support NEON and AVX, and they belong to different architectures, so you can't build them together.
However looks like SSE support is coming, thanks to Sasaono's fine work: https://github.com/drowe67/LPCNet/pull/25 which is the point where something like your suggestion will be useful Bruce ... - David On 26/4/20 1:35 pm, Bruce Perens via Freetel-codec2 wrote: > Why not combine the CPU-specific math accelerator libraries, and set > function pointers at runtime? It would be fewer builds, more distro > friendly, and less configuration when building from source. > > On Sat, Apr 25, 2020, 3:17 PM David Rowe <[email protected] > <mailto:[email protected]>> wrote: > > Hi Richard, > > Pls be careful putting too much work into this. I estimate the actual > number of people using FreeDV from a package/distro to be quite low. > > I'd estimate 90% of the end users run Windows, and most of the open > source community build from source. > > For the purposes of experimentation/development the current build system > is working well. You've done a fine job with cmake. We have a simple > build process (build.sh) that works on many flavors of Linux and I can > build Windows versions easily using Docker/Fedora (thanks Danilo!). > > So perhaps consider a "graded" approach to improve packaging - make some > simple tweaks for now (perhaps what you've done already), and consider a > major revamp down the track if warranted. > > Cheers, > David > > On 25/4/20 9:26 pm, Richard Shaw wrote: > > Ok, so we need a new approach... > > > > 1. Bundle (known good?) snapshots of LPCNet into FreeDV and either > > statically link, or at least make the library "private", i.e.: > > /usr/lib{,64}/freedv on RPM based systems. > > > > We can either copy it in, which I hate for one reason, or use git > > submodules which I hate for another: > > > > With copying it it, we're adding a lot of duplicate data into git, > which > > I don't like. > > > > With git submodules, github doesn't handle this very gracefully. You > > have to upload your own archives to include them and you can't > turn off > > the "on the fly" archives and they do NOT include the submodules. > > > > What's nice about them is that you can point to a specific commit > (or a > > branch or tag probably) so the version you "get" in the submodule > is fixed. > > > > Then we could update the CMake config of LCPNet to be smart enough to > > know if it's a stand alone build, or being called by FreeDV's > cmake and > > act appropriately. > > > > 2. Use the github "on-the-fly" archives for Freedv but upload "known > > good" archives of LPCNet and the module data with the release. > > Simplifies stuff for us a lot, but it will take more work for the > end user. > > > > Thoughts? > > > > Thanks, > > Richard > > KF5OIM > > > > > > > > > > _______________________________________________ > > Freetel-codec2 mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
