discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] GNU Radio Using MacPorts


From: Michael Dickens
Subject: [Discuss-gnuradio] GNU Radio Using MacPorts
Date: Tue, 20 Nov 2012 14:35:14 -0500

I just updated the GNU Radio ports in MacPorts to the latest release (3.6.2), 
GIT master (commit afea463f07), and GIT Next branch (commit c0b35b4ec7).  By 
using a single Portfile for all 3 versions, I should be able to maintain the 
ports more easily and keep the more up to date as releases and GIT commits 
happen.

If you're using OSX, any version though MacPorts targets 10.5 and newer, I 
would appreciate your feedback as to whether these ports work for you or not.  
Well, OK, the Next port won't yet due to some issue with Boost and the real 
time clock; but, this is known to GR developers and they're working on it 
(right?).  The other ports should work, with GCC or Clang as you like.

Along the way, I came upon 3 issues:

1) Clang and ASM don't play nice with ".version" commands.  Tom has already 
addressed this in a patch, but it's not yet in the GIT master or next branch.  
I am using that patch in my port until it is no longer necessary.

2) If GNU Radio is already installed (e.g., by MacPorts), then <gruel/*.h> will 
be picked up as dependencies from the already-installed files rather than from 
the current build.  I work around this (at least partially) by modifying the 
CMake "build.make" dependencies to be the correct files (those in the current 
build).  I've looked at the build debug output, and it seems OK -- so, I'm 
thinking this is more of a CMake internal issue (in the way it determines 
dependencies) rather than a GNU Radio CMake build script issue (in the ordering 
of dependency directories).  But, maybe not?  Anyway, thought folks might want 
to know.  I know I've encountered this issue before; it requires that one 
uninstall GNU Radio, re-do the CMake command, and then the build works.

3) Python scripts are installed into ${prefix}/lib/pythonX.Y/site-packages .  
Always.  And I cannot change this setting to the best of my reading.  I use a 
post-destroot hook that moves the whole site-packages directory into the 
appropriate Python MacPorts framework directory.  It would be good to be able 
to control where these files are placed via some CMake command-line option.

Enjoy! - MLD




reply via email to

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