Re: [Discuss-gnuradio] GNU Radio Using MacPorts

[Tom Rondeau]

On Tue, Nov 20, 2012 at 2:35 PM, Michael Dickens <address@hidden> wrote:
> 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.

Thanks for the good work!


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

Well, no complaints on this branch so far. I've been letting it sit
for a while, but as is always the case, we won't get good test
coverage until we merge it in.

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

This should be the GR_PYTHON_DIR variable. All of the install rules
for Python files have:

DESTINATION ${GR_PYTHON_DIR}/gnuradio/<component>

This always gets set in GrPython.cmake, but this simple patch would
allow us to set it on the cmake command line with
"-DGR_PYTHON_DIR=<your destination>":

diff --git a/cmake/Modules/GrPython.cmake b/cmake/Modules/GrPython.cmake
index 14f2b29..5287955 100644
--- a/cmake/Modules/GrPython.cmake
+++ b/cmake/Modules/GrPython.cmake
@@ -96,11 +96,13 @@ endmacro(GR_PYTHON_CHECK_MODULE)
 ########################################################################
 # Sets the python installation directory GR_PYTHON_DIR
 ########################################################################
+if(GR_PYTHON_DIR STREQUAL "")
 execute_process(COMMAND ${PYTHON_EXECUTABLE} -c "
 from distutils import sysconfig
 print sysconfig.get_python_lib(plat_specific=True, prefix='')
 " OUTPUT_VARIABLE GR_PYTHON_DIR OUTPUT_STRIP_TRAILING_WHITESPACE
 )
+endif()
 file(TO_CMAKE_PATH ${GR_PYTHON_DIR} GR_PYTHON_DIR)

 ########################################################################


I'm not sure if this is the 'cmake way' of doing something like this,
but it's simple and works.

Tom


> Enjoy! - MLD