# Idea for gr-modtool **URL:** \ **Category:** GNU Radio\ **Created:** [May 27, 2014, 2:53pm UTC](https://www.ruby-forum.com/t/idea-for-gr-modtool/230021 "2014-05-27T14:53:46Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\ **Post date:** [May 27, 2014, 2:53pm UTC](https://www.ruby-forum.com/t/idea-for-gr-modtool/230021/1 "2014-05-27T14:53:46Z")
Over the weekend, I helped out a couple people trying out the gr-howto example on OSX \< [http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules](http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules) \>. The common are of issue – which admittedly is primarily an OSX issue – is that the Python info which was used by GNU Radio’s CMake build system was not carried over into gr-modtool’s CMake build system. Instead, the latter looks for Python again – and, in this case if the correct CMake flags are -not- set, then CMake finds the system install of Python instead of the MacPorts version. Since these folks are using GNU Radio as installed by MacPorts, it’s quite important for the Python being used (header, library, executable, and GR\_PYTHON\_DIR location) to be the same between the main GR install and whatever gr-modtool sets up. So, my proposal is to modify gr-modtool to hard-wire these variables as found for the main GR install. And, any other variables that make sense to add in – basically: why re-find the wheel? I think the Python ones are the only critical ones (for proper execution), but there are likely a few for document building that could also be added. Thoughts? - MLD ---
**Author:** ![mdeering](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/278dde/32.png) [@mdeering](https://www.ruby-forum.com/u/mdeering)\ **Post date:** [May 27, 2014, 3:03pm UTC](https://www.ruby-forum.com/t/idea-for-gr-modtool/230021/2 "2014-05-27T15:03:43Z")
Hi Michael, > So, my proposal is to modify gr-modtool to hard-wire these variables as found > for the main GR install. And, any other variables that make sense to add in – > basically: why re-find the wheel? I think the Python ones are the only critical > ones (for proper execution), but there are likely a few for document building that > could also be added. Thoughts? - MLD Bad idea IMHO. The goal of gr-modtool is to create modules that will be usable easily by other GR users. If you start hardcoding stuff, then it will be non-buildable by anyone except the exact person who created the modules. If custom options are needed, a better approach would be to have an ‘option file’ or cmake wrapper that would be created by macport (and pybombs) that would automatically add the required options. something like : gr-cmake .. instead of cmake alone. Cheers, Sylvain ---
**Author:** ![mdeering](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/278dde/32.png) [@mdeering](https://www.ruby-forum.com/u/mdeering)\ **Post date:** [May 27, 2014, 4:27pm UTC](https://www.ruby-forum.com/t/idea-for-gr-modtool/230021/3 "2014-05-27T16:27:09Z")
On Tue, May 27, 2014 at 9:02 AM, Sylvain M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > The goal of gr-modtool is to create modules that will be usable easily > gr-cmake .. instead of cmake alone. > > Cheers, > > Sylvain I’m with Sylvain that hard-coding that information in gr-modtool is a bad idea for the same reasons. If someone develops it on OS X and then wants to distribute that project to other people working on other systems, we need to re-find everything there, too. The two aren’t and can’t be that coupled together. Tom ---
**Author:** ![mdeering](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/278dde/32.png) [@mdeering](https://www.ruby-forum.com/u/mdeering)\ **Post date:** [May 27, 2014, 4:36pm UTC](https://www.ruby-forum.com/t/idea-for-gr-modtool/230021/4 "2014-05-27T16:36:29Z")
OK; good arguments. Hard-coding into OOT module == bad. Agreed. Maybe something more along the lines of: When GR is installed, create a “${prefix}/etc/gnuradio/install.cfg” file that contains what GR CMake found, in a file that’s easily loadable by CMake. Then in the gr-modtool OOT module CMake look for this file and if found load it to get the correct values. This way, the gr-modtool installs will all be consistent on the local OS globally (for any user doing an OOT module) but OOT modules will not contain hard-wired settings. That seems better to me. Thoughts on this version? - MLD ---
**Author:** ![mdeering](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/278dde/32.png) [@mdeering](https://www.ruby-forum.com/u/mdeering)\ **Post date:** [May 31, 2014, 5:06pm UTC](https://www.ruby-forum.com/t/idea-for-gr-modtool/230021/5 "2014-05-31T17:06:31Z")
Thoughts on my proposal, below? - MLD On May 27, 2014, at 10:33 AM, Michael D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: Maybe something more along the lines of: When GR is installed, create a “${prefix}/etc/gnuradio/install.cfg” file that contains what GR CMake found, in a file that’s easily loadable by CMake. Then in the gr-modtool OOT module CMake look for this file and if found load it to get the correct values. This way, the gr-modtool installs will all be consistent on the local OS globally (for any user doing an OOT module) but OOT modules will not contain hard-wired settings.