On Sat, Apr 20, 2013 at 3:25 AM, Jan Schiefer <[email protected]> wrote:
> On 04/19/2013 04:01 PM, Richard Shaw wrote:
>
> On Fri, Apr 19, 2013 at 12:09 AM, Jan Schiefer 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.
>
>
> That's what I meant. If there is a config.h.in for autotools and a
> config.h.in.CMake for CMake (the input files have different formats), then
> you can say in your CMakeLists.txt something like:
>
I went ahead and called mine config.h.in but put it in a cmake
subdirectory. I figure over time some more stuff will end up there.
> Do you need anything other than the current functions and headers that
> are being checked in the config.h?
>
> You mean the new config.h that you just added in rev. 1234? I haven't
> checked fdmdv2 yet, only codec2. But codec2 would need checks for unistd.h,
> getopt.h and round().
>
Ok, I can add those.
> By the way, it seems there is a typo in the config.h.in: HAVE_STDINT_H
> should probably be HAVE_STDIN_H? The line is also duplicated.
>
Dang it. I thought I had already caught and fixed that. Actually know I did
but I lost my ssh connection from work to home and assumed the vi swp file
had the change. Guess not.
> 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.
>
>
> Yeah, right now I'm just checking for them, I assume it does not cause
> the config to error out, right?
>
> round() isn't checked for yet. It is fine for the config but errors out on
> compile.
>
> 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. 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).
>
> OK, not sure what the conventions are, and how the CMake searching works
> on Windows. I'll look at some other projects for inspiration.
>
The current convention for the freedv project seems to be to download the
required libraries on the fly during build, compile them, and then
statically link to them. It may take we a little while to re-implement that
in cmake and add the logic necessary so that system installed libraries
will be preferred over static linking.
>
>
> 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.
>
>
> Looks like the options are:
> 1) Adopt the Linux visibility approach: make all functions in a shared
> library accessible to programs linking against them
> 2) Link c2sim statically with codec2
> 3) Don't build c2sim on Windows
>
> If this was work, I'd say 'use option 2 to keep the number of public API
> functions minimal". But as this is ham radio, I prefer option 1 to make it
> easy to tinker. Opinions, anyone?
>
Yeah static linking for official linux packaging is a big no-no for
security reasons. With shared libraries, if a vulnerability is found in a
library then only the one needs to be updated. With static linking, every
package included in the distribution has to be updated, and that's if you
can find every one of them.
On windows I think static linking is much more common just from an ease of
use perspective because Windows doesn't have the linux equivalent of a
package manager + repository to automatically pull in dependencies.
> 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 :)
>
> Great, I'll keep my eyes peeled for changes.
>
> I wish this was on github :-).
>
Me too. That would make pull requests possible.
On a side note I've got basic NSIS packaging working for Codec2. I need to
commit some tweaks I've done since trying it out in my XP VM.
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
