Building with MSVC v16

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.

) 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?

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

*) 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?

*) gr-fec/lib/ber_tools.cc should IMHO have a “config.h” too.

*) 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?

–gv

On Thu, Oct 2, 2014 at 12:45 PM, Gisle V. [email protected] 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 R., 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.

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

“Tom R.” [email protected] wrote:

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 R., require VS 2012 or something (really
not sure, but I believe later than what you’re using).

I use VS 2010 and Ettus, yes seems to be using VS 2012. I fail to see
why
VS 2010 isn’t good enough. It was little tweaking to get it to work.

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.

Adding a “#include <iso646.h>” to my specially crafted “config.h” fixed
that.
GCC includes that unconditionally (thanks to Josh B. for tipping me on
that).

–gv