Forum: GNU Radio Re: Building with CMake on Win7 with MSVC 2008

OK, so here's what I've done to get it to build:

- To build gnuradio-core, comment out lines in
D:\gnuradio\src\gnuradio-3.3.0\gnuradio-core\src\lib\io\CMakeLists.txt
    #${CMAKE_CURRENT_SOURCE_DIR}/gr_stream_pdu_base.cc
    #${CMAKE_CURRENT_SOURCE_DIR}/gr_stream_pdu_base.h
    #gr_tuntap_pdu
    #gr_socket_pdu

- Remove
    #include <gr_pdu.h>
    #include <gr_tuntap_pdu.h>
    #include <gr_socket_pdu.h>
    %include "gr_pdu.i"
    %include "gr_tuntap_pdu.i"
    %include "gr_socket_pdu.i"
from D:\gnuradio\src\gnuradio-3.3.0\gnuradio-core\src\lib\io

It seems that these new modules (added to git 5 days ago) don't play 
nicely
with CMake on windows (the libraries required only exist on Linux 
anyway)

- To build gnuradio-audio, add #include <io.h> to 
audio_portaudio_source.cc
and audio_portaudio_sink.cc

- Add boost.Chrono library input to linker missing from projects:
fcd_nfm_rx
dial_tone
_filter_swig
_fft_swig
_fcd_swig
_pager_swig
_digital_swig
_vocoder_swig
_blocks_swig
_audio_swig
_analog_swig

With these modifications, it builds on MSVC 2008.

I am now getting issues with RUN_TESTS - they all seem to fail. However,
after running the INSTALL build and testing in Python, it seems like 
most
things work. How can I ascertain the causes of these test failures?

My main objective with this was to get the portaudio source working - I
believe this was not compiled with the precompiled binaries from Ettus
Research, which is what started me off compiling in the first place. The
audio sink appears to work fine, but the audio source does not:
audio_copy.py simply exits after the call to run(), without an error
message (there are a couple of complaints about invalid arguments to
gr_vmcircbuf_default_factory, but that usually doesn't stop the whole 
thing
from working). Does anyone know how I can debug this?

On 12/12/2012 07:40 AM, wakjah ' wrote:
>     #include <gr_pdu.h>
>     #include <gr_tuntap_pdu.h>
>     #include <gr_socket_pdu.h>
>     %include "gr_pdu.i"
>     %include "gr_tuntap_pdu.i"
>     %include "gr_socket_pdu.i"
> from D:\gnuradio\src\gnuradio-3.3.0\gnuradio-core\src\lib\io
>
> It seems that these new modules (added to git 5 days ago) don't play nicely
> with CMake on windows (the libraries required only exist on Linux anyway)
>

It seems like some unstable stuff was merged into master. Can you post
the error? I understand the tuntap issue. But I'm not sure about the
others...

> - To build gnuradio-audio, add #include <io.h> to audio_portaudio_source.cc
> and audio_portaudio_sink.cc

can you post the patch?

http://gnuradio.org/redmine/issues/495

> _blocks_swig
> _audio_swig
> _analog_swig
>
> With these modifications, it builds on MSVC 2008.
>

Interesting, I think one of the boost dependencies pulls in another
boost dependency that we dont normally link against. My reference is
boost 1.47.

What version of boost are you using?

Can you post the patch for this?


> I am now getting issues with RUN_TESTS - they all seem to fail. However,
> after running the INSTALL build and testing in Python, it seems like most
> things work. How can I ascertain the causes of these test failures?
>

Usually its an issue of something missing from the %PATH%. The test
scripts attempt to set the environment variables so that in-tree build
products are in the PATH, but probably not out of tree dependencies. It
may be good to run dependency walker and see what is "missing"

> My main objective with this was to get the portaudio source working - I
> believe this was not compiled with the precompiled binaries from Ettus
> Research, which is what started me off compiling in the first place. The
> audio sink appears to work fine, but the audio source does not:
> audio_copy.py simply exits after the call to run(), without an error

I think the windows audio source implementation is empty!
http://gnuradio.org/redmine/issues/496

> message (there are a couple of complaints about invalid arguments to
> gr_vmcircbuf_default_factory, but that usually doesn't stop the whole thing
> from working). Does anyone know how I can debug this?
>
>

That print is safe to ignore.

-josh

Actually, I'm not sure that it was strictly necessary to remove all of
those from the make list; I just removed what I *thought* was affecting 
it
(anything that referenced if_tun.h - even if it was within a #if/#endif)
and it seemed to work.

With regards to posting patches... yes, I can, but I'm not sure how. I
understand that I need to use git format-patch, but do I have to commit
beforehand? I thought the idea was that I would create a patch and 
submit
it, and then someone would commit and merge the patch later on, but I 
can't
see how to get format-patch to work unless I commit (sorry, first time
using git :) )

I am using boost 1.51 - I previously had an earlier version that I had
compiled, but at some point I downloaded the prebuilt binaries to try 
and
fix an issue. It didn't fix the issue, but now I have the latest version 
of
boost :)

As for the windows audio sources: yes, the windows audio source is 
empty,
but the portaudio one is not. In order to get it to work I had to set
audio_module = portaudio in C:\Program Files
(x86)\gnuradio\etc\gnuradio\conf.d\gr-audio.conf. I think there might 
also
be a way involving importing only the audio_portaudio module in Python, 
but
I haven't investigated this yet. You also have to make sure you get the
device name right, or it'll do nothing. For a while I thought I should 
be
setting the device name to portaudio to tell the factory to create a
portaudio source, but I was wrong - the documentation could be a little
clearer on this.

On 12/13/2012 08:17 AM, wakjah ' wrote:
> Actually, I'm not sure that it was strictly necessary to remove all of
> those from the make list; I just removed what I *thought* was affecting it
> (anything that referenced if_tun.h - even if it was within a #if/#endif)
> and it seemed to work.
>

OK cool, thats what I thought. I think there was a patch merged for this
ifdef yesterday after you reported the bug.

> With regards to posting patches... yes, I can, but I'm not sure how. I
> understand that I need to use git format-patch, but do I have to commit
> beforehand? I thought the idea was that I would create a patch and submit
> it, and then someone would commit and merge the patch later on, but I can't
> see how to get format-patch to work unless I commit (sorry, first time
> using git :) )

just send the output of "git diff" :-)

> be a way involving importing only the audio_portaudio module in Python, but
> I haven't investigated this yet. You also have to make sure you get the
> device name right, or it'll do nothing. For a while I thought I should be
> setting the device name to portaudio to tell the factory to create a
> portaudio source, but I was wrong - the documentation could be a little
> clearer on this.
>

There is only one audio source/sink block. The underlying implementation
is chosen based on compilation support and preference setting. So
setting the conf file is probably the best way to do this.

-josh