Re: [Discuss-gnuradio] GR 3.5.1 release tarball bugs

[Josh Blum]

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