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 <da...@rowetel.com> 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
> > Freetel-codec2@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> >
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to