Helps if I subscribe THEN reply...
On Thu, Apr 11, 2013 at 12:47 PM, Bruce Perens <[email protected]> wrote:
> I have moved this discussion to [email protected], as
> digitalvoice is supposed to be a user list. Richard, please subscribe at
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> if you have not already done so.
>
Just did! Thanks.
> On 4/11/2013 7:24 AM, Richard wrote:
>
> One thing I've run into is that the autoconf/automake configuration needs
> some significant tweaking in some cases and to be honest, I'm not very good
> with it, so my "fixes" have been very much hacks.
>
> I congratulate you on your politeness in speaking of autoconf/automake. I
> personally could not describe it sufficiently without, I suspect, first
> learning how to swear in Arabic. It's definitely time to move on to
> something else.
>
> I'm *more* comfortable in the cmake arena although I'm no expert.
>
> That's fine. If you would jump right in and try to make it work
> side-by-side with the present stuff so that autoconf/automake does not
> break, that would greatly facilitate cutting over. You might have to use
> alternate names for Makefiles and invoke them with "make -f". But it seems
> to me that this could be done.
>
The easiest solution here is that for cmake, the preference to do
out-of-source builds, i.e.:
mkdir build_linux && cd build_linux
cmake ../
make
etc.
This method would not clobber Makefile but then again, if you're doing a
cmake instead of automake build, do you really care if you clobber
Makefile? You can always regenerate it.
> Some questions/suggestions for Codec2:
> There are some VERY generic names for the headers (sine.h, fft,h, etc)
> which could very likely conflict with existing linux packages so for my RPM
> I moved them into /usr/include/cocdec2/. Theoretically I could have left
> codec2.h in /usr/include but from a hack perspective it was easier to move
> all of them.
>
> Yes, it is simply good engineering to put these in a codec2 directory *if
> they are installed at all.*
>
Yes. I fixed part of my problem by using a svn checkout of codec2-dev
instead of codec2, which does not provide golay23.h, however, freedv seems
to still need a couple of the non-fdmdv prefixed headers.
> Also, there seems to be a need for more tweaking on exactly what headers
> get installed...
>
> It might be that some of this code is shared between our modems, codec,
> and freedv, but they shouldn't be exposed outside of the project's own
> compilation directories. One should only need to place headers that define
> external APIs under /usr/include .
>
Sounds like that's the best solution...
> FreeDV:
> Although not required, it's generally preferred to name the package the
> same as the source archive, but fdmdv doesn't exactly roll off the tongue...
>
> FDMDV is the name of someone else's application from which we cribbed the
> modem design and perhaps some UI elements, but nothing copyrighted.
> Actually, we use it more for the HF modem today than the application. We
> can change that sometime, probably with a major version change.
>
Sounds good to me.
> I've begun work on creating a cmake configuration starting with
> configure.ac and got a lot of the library detection working and checking
> for headers. My next step is to re-implement the function checks.
>
> The real trick is getting it to work on Linux (.rpm|.deb), *BSD, Windows,
> MacOS, and (libraries only) cross-compile to Android. This is a good reason
> that present stuff should be left standing alongside for a while.
>
cmake is very cross platform usable (linux, BSD, OSX, MSVC, etc) but I'm
not sure about Android unless it would use the standard ARM type target
which a google search seems to support.
> I guess my question to the group is: Is there any interest in supporting
> a cmake based build?
>
> Very much so. The only reason it's not being done is that the other
> developers are having life get in the way. If you can put in the time we'd
> be very appreciative.
>
Well I've had time since the original email and I've actually got a
rudemintary build working except while the codec2-dev provides golay23.h,
the functions don't seem to be backing it into libcodec2.so...
fdmdv2_main.cpp:(.text+0x2a4a): undefined reference to `golay23_init'
CMakeFiles/freedv.dir/fdmdv2_main.cpp.o: In function
`per_frame_rx_processing(FIFO*, int*, FIFO*, int*, int*, CODEC2*)':
fdmdv2_main.cpp:(.text+0xcf30): undefined reference to `golay23_decode'
fdmdv2_main.cpp:(.text+0xcf42): undefined reference to
`golay23_count_errors'
fdmdv2_main.cpp:(.text+0xd029): undefined reference to `golay23_decode'
fdmdv2_main.cpp:(.text+0xd03b): undefined reference to
`golay23_count_errors'
fdmdv2_main.cpp:(.text+0xd174): undefined reference to `golay23_decode'
fdmdv2_main.cpp:(.text+0xd186): undefined reference to
`golay23_count_errors'
CMakeFiles/freedv.dir/fdmdv2_main.cpp.o: In function
`per_frame_tx_processing(short*, short*, CODEC2*)':
fdmdv2_main.cpp:(.text+0xd697): undefined reference to `golay23_encode'
fdmdv2_main.cpp:(.text+0xd6d5): undefined reference to `golay23_encode'
fdmdv2_main.cpp:(.text+0xd80a): undefined reference to `golay23_encode'
collect2: error: ld returned 1 exit status
On Thu, Apr 11, 2013 at 12:57 PM, Bruce Perens <[email protected]> wrote:
> I think you will find it most convenient at the moment to have a local
> build of wxWidgets. Linux distributions are somewhat behind in their
> adoption of new wx versions, and this will avoid some rather tedious
> backporting.
>
The current Fedora maintainer already had a working parallel-installable
source RPM of wxWidgets 2.9 (wxGTK3 on Fedora) which I'm successfully
building against. Because 2.9 is the unstable future 3.0 version, he just
doesn't have any interest in maintaining it until the stable 3.0 release so
I may have to do that.
Thanks,
Richard
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
