I was just trying to install the GnuRadio 3.5.1 release tarball, and I
found two problems:
The tarball does not appear to contain the CMakeLists.txt file.
This forces the use of the autotools instead of cmake.
After successfully installing UHD release 3.3.2, the GnuRadio
configure script failed to configure gr-uhd. The reported reason
was
configure:28430: $PKG_CONFIG --exists --print-errors "uhd >=3.0.0
uhd < 4.0.0
Package libusb-1.0 was not found in the pkg-config search path.
…
Package ‘libusb-1.0’ , required by ‘UHD’, not found.
==============================
This error message is incorrect. libusb-1.0-0 WAS installed. What
was actually missing was libusb-1.0-0-dev. Installing that package
allowed gr-uhd to be configured.
I was just trying to install the GnuRadio 3.5.1 release tarball, and I
found two problems:
The tarball does not appear to contain the CMakeLists.txt file.
This forces the use of the autotools instead of cmake.
I dont think this is a tarball of the source tree. Rather, its a tarball
produced by autotools with only files listed by makefile.ams or
generated in autotools.
==============================
This error message is incorrect. libusb-1.0-0 WAS installed. What
was actually missing was libusb-1.0-0-dev. Installing that package
allowed gr-uhd to be configured.
So UHD creates uhd.pc with the following line when orc and libusb are
found: Requires.private: libusb-1.0 orc-0.4
Technically, that seems to be the correct thing to do for pc files. But
the side effect seems to be that package config complains when it cant
find a pc file for the “Requires.private” entries. But you shouldnt
actually need the development libraries required by uhd to be installed
to develop against uhd.
I’m happy to not have UHD populate Requires.private if its just trouble.
In anycase, this probably isnt an issue with the gr tarball. A good test
of that might be to uninstall the libusb-1.0 dev and see if pkg-config
uhd --libs gives the same error. That way we can tell if auto* is doing
something different with pkg-config or not.
Maybe someone with more pkgconfig experience jump in here.
I dont think this is a tarball of the source tree. Rather, its a tarball
produced by autotools with only files listed by makefile.ams or
generated in autotools.
But what of the future? If autotools goes away in favor of cmake, does
this mean that tarballs will go away too? I hope not, as a tarball is
the preferred way of installation on a number of the machines that I use
because they are in isolated labs and are not allowed to be connected
to the internet.
something different with pkg-config or not.
I don’t know about this pkg-config behavior, as I installed UHD release
3.3.2 from the prebuilt binary package for Ubuntu.
And just as a side note (I know this should really go on the ettus
list), the aforementioned UHD binary Ubuntu package did not unpack the
images subdirectory properly. All that was there was the .tar.gz and
.zip files. I had to manually gunzip/untar and move all the image
files to the proper locations by hand.
One suggestion I have, is if we pushed all of the tags onto github,
github will happily give your source tarballs for any particular branch,
or tag, or revision. Example:
I don’t know about this pkg-config behavior, as I installed UHD release
3.3.2 from the prebuilt binary package for Ubuntu.
Seems requires.private basically forces pkg-config to search for the
development libraries, even if its not technically needed. I wonder what
the difference is between the private and regular entries: http://people.freedesktop.org/~dbn/pkg-config-guide.html
Anyway, I think the best thing to do would be to just turn off
Requires.private for the case of building release packages, and maybe
altogether. That’ll fix it.
And just as a side note (I know this should really go on the ettus
list), the aforementioned UHD binary Ubuntu package did not unpack the
images subdirectory properly. All that was there was the .tar.gz and
.zip files. I had to manually gunzip/untar and move all the image
files to the proper locations by hand.
the preferred way of installation on a number of the machines that I use
I will pipe in here with how I handle my interweb-disconnected
machines: I have the git repo cloned onto a flash drive, and
clone/pull from that on the disconnected machine(s) when needed: a
nice feature of a DVCS. This does assume that moving flash drives
between machines is allowed.
However, since I imagine there are plenty of people who don’t really
want to go through the additional step of dealing with git (if they’re
used to building from tarballs), I believe cmake has the ability to
create them using the make package_source command, but I admit I’ve
never tried this with GNURadio, and have no idea how well it
does/doesn’t work. Note that cmake-produced tarballs do require cmake
to exist on the machine doing the build (whereas autotools generated
tarballs only assume the Bourne shell+required compilers/etc. are
available).
On Thu, Jan 12, 2012 at 1:53 PM, Ed Criscuolo [email protected]wrote:
because they are in isolated labs and are not allowed to be connected
to the internet.
Absolutely not! We will always have release tarballs available.
Right now, we use the “make dist” target that autotools creates, but
that’s
a convenience, not a requirement.
In fact, you can get weekly builds from the website as generated by
Jenkins. I have a script that runs to create a full tarball of the code
every Monday, and this includes the cmake install.
Yea, thats exactly the case. So, the package_source target will
basically tar/zip/7 up the source tree as it is. I suspect part of its
utility comes from the fact that someone may want to include extra stuff
into the source tree as part of the build. I guess it also simplifies
calling the commands and putting version numbers on the files. I think
the whole github doing it automatically for you is pretty swell, but
anyhow, this works to the same effect.
-Josh
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
