I’m working (again) on the MacPorts port and files associated with
GNU Radio, playing with GNU Radio’s “Build Configuration” options in
order to get a separate package for each component (e.g. one each for
“gnuradio-core”, “usrp”, “gr-usrp”, and so forth). I note that on
the BuildConfiguration wiki page < http://www.gnuradio.org/trac/wiki/
BuildConfiguration >, under “WARNING” it reads:
“Individual GNU Radio components may depend upon other components
(such as gnuradio-core) to successfully compile. In particular,
during a build the library and include search paths point to the
current build tree, not the system installation path. So one will
need to either have compiled the dependent components already in a
prior build (not necessary to install them), or one will have to
build all the related components at once.”
While this is desirable from the perspective of maintaining
consistency among the various components (same version, or save SVN
revision; when one is updated, the other will be recompiled as well,
and so forth), it makes building separate components somewhat of a
PITA when using MacPorts:
-
creating the gnuradio-core package requires just omnithread, which
is fine since that’s not a big extra compile, but …
-
creating the gr-usrp package requires the (re)compilation of usrp,
gnuradio-core, and omnithread … which is “up there” in terms of time
because of (re)compiling gnuradio-core.
For MacPorts, I don’t have the option of re-using a single compiled
trunk or tarball; I have to recompile everything for each component.
While I can write Portfile’s that can do this, it would be easier if
there was a way around it - using some specific CONFIGURE options or
MAKE environment variables that do allow for compiling just the
component itself instead of it and all of its dependencies (which are
already installed by MacPorts).
Anyone know how to do this, or is it really just impossible? - MLD
On Thu, Jan 17, 2008 at 09:54:55AM -0500, Michael D. wrote:
library and include search paths point to the current build tree, not the
fine since that’s not a big extra compile, but …
it and all of its dependencies (which are already installed by MacPorts).
Anyone know how to do this, or is it really just impossible? - MLD
Michael, this is ticket:186, “Add option to disable intree
dependencies”, aka the “pkgsrc enhancement”. Right now it’s not
possible.
Eric
On Jan 17, 2008, at 1:14 PM, Eric B. wrote:
Michael, this is ticket:186, “Add option to disable intree
dependencies”, aka the “pkgsrc enhancement”. Right now it’s not
possible.
OK. Good to know it’s in the queue somewhere. Any idea how
difficult this would be to implement? Any hints on getting started?
I’m writing a paper right now that’s due Feb 1, and need some
alternative-activity time every so often, and if I could figure out
what to do it would “kill multiple birds with one stone” as the
saying sort of goes. - MLD
On Thu, Jan 17, 2008 at 01:35:50PM -0500, Michael D. wrote:
On Jan 17, 2008, at 1:14 PM, Eric B. wrote:
Michael, this is ticket:186, “Add option to disable intree
dependencies”, aka the “pkgsrc enhancement”. Right now it’s not
possible.
OK. Good to know it’s in the queue somewhere. Any idea how difficult this
would be to implement? Any hints on getting started? I’m writing a paper
right now that’s due Feb 1, and need some alternative-activity time every
so often, and if I could figure out what to do it would “kill multiple
birds with one stone” as the saying sort of goes. - MLD
I think the first thing is to decide how you want it to behave, and
what configure time options you’d want.
I want to maintain the current behavior as the default, as it allows
us to robustly test in the build tree prior to installing using make
check.
You should think carefully about how you want linking and “make check”
to work in the case where you’re pulling some stuff from the build
tree and some from the installed location. How are you going to
specify which libraries are loaded from which locations, etc?
Finally, I’d worry about how to implement this so that it’s clean and
transparent to 95% of the code. That is, find a way to hide the hair
in one or two places. Makefile.common might be one of them.
Good luck on the paper, and “killing multiple birds”.
Eric