discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Discuss-gnuradio] MSVC porting


From: Geof Nieboer
Subject: RE: [Discuss-gnuradio] MSVC porting
Date: Thu, 1 May 2008 13:08:15 +0900

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:address@hidden 
Sent: Wednesday, April 30, 2008 1:54 AM
To: Geof Nieboer
Cc: address@hidden
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]