Re: [Discuss-gnuradio] Building with CMake on Win7 with MSVC 2008

[Josh Blum]

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" :-)

> 
> 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.
> 

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

> 
> On Wed, Dec 12, 2012 at 3:06 PM, Josh Blum <address@hidden> wrote:
> 
>>
>>
>> On 12/12/2012 07:40 AM, wakjah ' wrote:
>>> 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)
>>>
>>
>> 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
>>
>>>
>>> - 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.
>>>
>>
>> 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
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>