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 <http://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:
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in.CMake
${CMAKE_CURRENT_BINARY_DIR}/config.h)
This way, both autotools and CMake with generate a config.h from their
respective .in files, and the results are compatible with each other.
I am not really interested in MSVC support for autotools. I'd rather
spend energy making the CMake build sufficiently complete and dumping
autotools as soon as practical.
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().
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.
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.
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, 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 :-).
Regards,
Jan
------------------------------------------------------------------------------
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
