Re: [Discuss-gnuradio] GNU Radio Using MacPorts

[Michael Dickens]

> I just recently caught one of these order of include paths in
> gr-uhd/swig. Its so easy to accidentally get it in the wrong order. I'd
> like to take a look: Can you say what component is pulling in the
> installed headers? Is it a specific component, swig module, etc?

Watching the debug output of the post-configure hook, which effectively issues 
a "sed" script to do the replacement, everything is effected.  It looks like 
the files of issue are "${prefix}/include/gruel/*.h".

> Also; There is also a little swig dependency searcher at the bottom of
> GrSwig.cmake. I wrote this, and its got its flaws.

I hadn't found that yet; I'll try to look at that today since it would be great 
to get this done.  Dependencies are a pain; I remember that distinctly when I 
(re)wrote the prior build system.

> If you configure,
> uninstall some public headers, and try to build, you may get an error
> until you reconfigure...
> 
> http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrSwig.cmake#n200

Yes, that's how I was testing for this issue.  I'd do what you wrote, then 
patch the "build.make" files until CMake was happy, then try again while 
watching the debug output; repeat.  That's how I found it was just gruel 
headers.

- MLD

ps> While we're on the subject of the build system, can I suggest a slight 
change to the printouts?  I'll search around a little this morning to see if I 
can change this myself, but maybe someone else (e.g., Josh) knows quickly where 
to look and how to change this.

What I'd like to see is if I disable a component on the cmake command line 
(e.g., "cmake -DENABLE_VOLK=NO"), then in the message printout is says that 
that component was disabled by the user (e.g., "Volk was disabled by the 
user.") or something like that.  Right now it just says that the component was 
disabled even if everything else was found -- and, thus, it's not clear where 
the issue might be (e.g, maybe it was something internal that isn't listed?).  
Stating that it was the user's explicit choice to disable the component would 
be good from a debug standpoint.

It would also be nice to not even do the checks for that component if it is 
disabled by the user.  Since each component's checks are independent (or, 
should be), this should be no issue.  I see that this happens with some 
components (e.g., gnuradio-core) but not others; or, at least partially they do.