On Mon, Jun 17, 2013 at 4:20 PM, David Rowe <[email protected]> wrote:
> Hi Richard,
>
> This sort of structural change is something we must collaborate on, as
> it impacts my day-day work on Codec 2 and FreeDV.
>
Sure. At this point nothing has been changed within the codec2-dev
directory, it was just a copy for development purposes.
>
> I agree it does make sense to move the fdmdv modem and golay code away
> from the codec, although the number of files is small at this stage
> (i.e. just 2 for the golay code). Not sure if this warrants an extra
> library. What do others on the list think?
>
I don't really have a problem with either direction, my only concern is
fdmdv2 reaching around into the codec2-dev directory for golay23.c.
>
> Some thoughts:
>
> + the golay codes implements forward error correction (FEC). Its a
> different layer from the modem. So the name "rfmodem" is not suitable.
>
> + Not sure about the name "rfmodem" for the fdmdv code. Once again RF
> is a different layer to the modem. "fdmdv" or "modem" would be a good
> name for the modem code, perhaps "fec" for the FEC code. generic names
> like modem/fec would support the addition of other modem/FEC code to the
> library later.
>
> + Pls ensure all programs using the golay code (and the modem code if
> you move that) still work, e.g. the unitttests and utilities in src, the
> various command line simulations, and FreeDV (Windows and Linux). This
> will require some maintenance and testing of the autotools &
> Makefile.linux/Makefile.win32 build system at this time. You can see
> how I used the command line simulations on the various FreeDV robustness
> blog posts.
>
Yes, there are a lot of test binaries in there, we need to document what
tests need to pass and how they are run. If we can develop this enough I
can automate the testing through ctest. My vote would be to not go live
with the separate rfmodem library (or whatever it's called) until the full
switch-over to cmake.
> + Structural changes are a "nice to have" for me. However it's more
> important to me that nothing breaks and _everything_ is thoroughly
> tested. If the structural changes can happen without anything breaking
> then that's great. I simply don't have the bandwidth to support these
> changes myself by tracking down any resulting build issues.
>
As more people get involved with coding I think we're going to need a more
disciplined approach to code changes including "branches" so work can be
done independently and then merged back into the main code base when
complete. I'm more familiar with how to do this on git (especially github)
than svn though...
Richard
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
