On Thu, Oct 2, 2014 at 12:45 PM, Gisle Vanem <gva...@yahoo.no> wrote:
> Hi list. > > I've managed to build Gr using MingW. Now trying the same > using Visual C Express 2010 (cl 16), gives me some troubles. > I'm just adding all my points here instead of multiple emails. > Just to begin with, we do not currently have good support and testing for Windows systems and are actively discussing how to handle this OS. I believe that any support for Windows at all, such as through the current binaries provided by Ettus Research, require VS 2012 or something (really not sure, but I believe later than what you're using). Watch out for a statement soon from us about our Windows efforts and support. Having said that, you bring up some good points. > *) reed-solomon/*.[ch] needs 'FIXED' to be defined since my cl > doesn't support variable arrays. What bad could happen with > 'FIXED' defined? Besides '-DFIXED' clashes enormously with the > wingdi.h header. So what about 'GR_FIXED_ARRAYS' instead? > This code has been around forever, and I believe it has built under Windows. I'd rather not change this right now. > *) The special C++10 (?) features like 'not', 'and' and 'or' doesn't work > here. Do they really bring anything new to Gr? > Ref. gr-blocks/lib/multiply_matrix_ff_impl.cc etc. > No they add nothing and I'm not a fan of them. My guess is that some of it was that code was prototyped in Python and converted over to C++ and these were carried along with it. It's a hard thing to grep for, but I'll be patching a few of the cases that I found. > *) gr-fcd/lib/hid/hid-libusb.c doesn't have a "config.h" test. I get > tons of errors if it's not these. I added pthreads-w32 to make it work, > but I'm not sure it's a good idea. Are you supporting HID devices on > Windows at all? > Nope. With our lack of Windows support in general right now, we certainly don't support this. We will actually be dropping support for gr-fcd in the future, too, since it's much easier for the hardware manufacturers to handle these issues than us. > *) gr-fec/lib/ber_tools.cc should IMHO have a "config.h" too. > That code shouldn't even be there. I meant to remove it when adding FEC API into GNU Radio, but with everything else going on there, this one slipped through. I'll be removing it since the only thing we used in it was the compber, which is easily replaced by popcount out of VOLK. Nothing was ever exported out of the library, anyways. > *) In gr-blocks/tests/benchmark_nco.cc and > gr-blocks/tests/benchmark_vco.cc: > > #include <gnuradio/blocks/nco.h> > #include <gnuradio/blocks/fxpt_nco.h> > > Shouldn't that be: > #include <gnuradio/nco.h> > #include <gnuradio/fxpt_nco.h> > > Seems like an oversigth (*nco.h was once under gr-blocks?) Or could it be > trouble at my end? > Yes, these were originally in gr-blocks and will be backed. > --gv > Thanks! Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
