One again got bit by gmail replying to the wrong copy of the email...
---------- Forwarded message ----------
From: Richard Shaw <[email protected]>
Date: Fri, Apr 19, 2013 at 7:57 AM
Subject: Re: codec2-dev CMake on Windows/VisualStudio
To: Jan Schiefer <[email protected]>
On Fri, Apr 19, 2013 at 12:09 AM, Jan Schiefer <[email protected]> wrote:
> A config.h file is needed to deal with some missing functionality in the
> Windows platform. I am able to make this work for both autoconf and CMake
> by using different input file names for the different environments and the
> same output file name. The HAVE_XXX mechanisms are pleasingly similar, so
> the #include works with output from either CMake or autoconf.
>
Sure. Creating a config.h.in for codec2 isn't a problem, but it sounds like
it should be included in the autotools config as well unless you're
thinking of not worrying about MSVC for autotools and just put all the
effort on the cmake config.
Do you need anything other than the current functions and headers that are
being checked in the config.h?
> On a related note, the list of include files and functions checked for is
> inconsistent between autoconf and CMake.
>
Yes. I had to add one or two headers (I forget which ones) to the codec2
install in order to get freedv to build. I'm not sure why they were
missing, unless they are only needed on certain platforms.
> VisualStudio doesn't have a round() function. Easy enough.
>
Yeah, right now I'm just checking for them, I assume it does not cause the
config to error out, right?
The question is, which ones are needed and which ones are optional, and on
what platforms. If we can figure that out, then I can put the required
logic into the cmake config so it will error out on configuration rather
than compilation, or worse, silently failing and creating a bad executable.
> It also doesn't have getopt(), which is used in c2sim. I have found a
> "Microsoftized" version of glibc's getopt() here:
> http://www.ludvikjerabek.com/**software<http://www.ludvikjerabek.com/software>.
> This is under LGPL, so the license is compatible. This raises the question
> where in the source tree platform dependent source files should go?
>
Well from a *nix perspective, it shouldn't. It should be installed
separately and be checked for availability during configuration. That being
said, bundling libraries is very common in upstream projects (and the bane
of my packaging existence).
If it is determined that it's best to bundle it then it should go into a
directory under codec2 such as "external" or something like that so
packagers know they there's a bundled library in the source.
Windows requires an explicit declaration which entry points are to be made
> visible ("exported") from a shared library. I solved this with an external
> declaration (DEF file). Since I did this, I have also noted that some of
> the "public" functions in the codec2 library are decorated with
> CODEC2_WIN32SUPPORT macros, so that may be the preferable approach? This
> would work for everything other than c2sim, which needs access to some of
> the more private parts of the codec2 library. Not sure what to do about
> that one.
>
Sorry to say, neither do I. I'm a fairly experienced packager but my coding
experience is very limited, largely to minor patches and hacks to make
stuff build.
> Now, for next steps: Any comments on the questions above would be
> appreciated. I need to finish up the integration of the getopt() stuff and
> do a little more testing, otherwise I will very soon be ready to provide
> patches, if desired. I should probably wait for the next set of changes and
> merge those out first? Seem you are hard at work.
>
Yeah, for codec2 I should hopefully have it more or less complete over the
next couple of days, maybe today. It just depends on how busy I am at work
:)
Eventually I will try the same with fdmdv2. I can help with OSX also, if
> nobody else is working on that.
That would be great. I've started working on a windows mingw build which
appears to work without any additional changes required, so that's good.
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
