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 >.
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
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
On Tue, May 27, 2014 at 9:02 AM, Sylvain M. [email protected]
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
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
Thoughts on my proposal, below? - MLD
On May 27, 2014, at 10:33 AM, Michael D.
[email protected] 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.