On 01/12/2012 10:53 AM, Ed Criscuolo wrote: > On 1/11/12 4:59 PM, Josh Blum wrote: >> 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. >
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: wget https://github.com/gnuradio/gnuradio/tarball/master wget https://github.com/gnuradio/gnuradio/tarball/<some tag name> >> 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. > > 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. > Whoops, thanks. I'll fix those today. -Josh _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
