Eric, Sounds good. As far as the VOR code, a previous version was on the mailing list (that version wasn't working but was close), and after I have a chance to clean up my current version, I'll post that as well.
I haven't done as much with that since I began to put the effort into porting the code. At the moment, I've got a good build of 90% of core, gr-usrp, and usrp into a shared DLL. I'm creating the Managed C++ shims now, and I'm going to do just enough to get the USB/USRP benchmark up and running in C# so I can validate that everything works end-to-end. I know the USRP works on it's own, but now this will actually build a graph and test it. Once I've got that done, I'll go back and revisit the VOR code in python and get that sorted. Then it'll be time to go back and make more shims :) I'll check into the automake system and see what can be done. I agree 2 build systems is not the best approach, so I'll investigate the automake system. A vcproj file is just XML, so it might be do-able. Geof -----Original Message----- From: Eric Blossom [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 1:54 AM To: Geof Nieboer Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] MSVC porting On Mon, Apr 21, 2008 at 12:24:06PM +0900, Geof Nieboer wrote: > All, > > After doing some 'proof of concept' with the VOR receiver (the phase > comparator still isn't perfect, but bad weather has given me a marginal > signal recently, so it's on hold for a tad), I've been really impressed with > gnuradio. It's only flaw it seems to me is that it's difficult for joe > average to install/use on their PC. So here's how I'd like to contribute: Great! Thanks for the update on your VOR receiver. I was thinking about it the other day. Can you post the link to your code? I may have missed it. > > 1- Tweak the C++ libraries so that they'll compile under windows > natively (MSVC++ 2005 specifically) > > 2- Add 'shims' to allow access to the C++ classes through .NET managed > code on windows > > 3- Convert select python applications to C# > > 4- Build a standalone install package (easy once 1/2/3 are done) > > I believe I've got a concept that will extend the functionality to a native > windows environment without complicating the linux build process. On my dev > machine, I've set up a gnuradio source tree (3.1.2), and added a directory > 'gnuradio.net'. The .vsproj files etc go there, as well as any managed code > (both Managed C++ and C# depending). Geof, the concern I have with this approach is that there will be two build systems in parallel, and one of them will be out of date with respect to the other 99.99999% of the time. I think an approach that could work would be to create a modified version of automake that reads the Makefile.am's and produces a project file instead of Makefile.in's. automake is a perl script, so all the parsing, logic, etc is already handled for you. You can probably dodge around configure.ac, by hardcoding some answers that are reasonable for the windows environment. Information on automake and links to the source can be found here: http://www.gnu.org/software/automake Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
