On Wed, Jan 8, 2014 at 10:40 PM, ikjtel <ikj12...@yahoo.com> wrote: > I found this bug to be very humorous ;-) > > In the case of a source download where the source file to be unpacked > is one of tar.gz or tgz or tar.bz2 or tbz2, you had better not make the > name of the recipe the same as the name of the top-level directory in the > archive. If you make them the same name, guess what happens in this > code in mod_pybombs/fetch.py: > rmrf(self.recipe.name); > os.rename(dirname, self.recipe.name); > > The rmrf nukes the unpacked source in its entirety ! > > On to the question - noticed that when pybombs builds boost it doesn't > seem to be using more than one CPU - i.e., it's like make -j1 - is there a > quick fix for this ? > > Best > > Max
Hi Max, Thanks for all your reports on this. What you mention here is definitely a bug. The issues you're having with UHD and libusb are a completely different matter. My guess is that there will be some change in UHD coming that will either fix the version issue or update their libusb version requirements (currently, UHD only says it depends on 1.0, which is what pybombs is relying on). But the bigger issue here is the same thing that we're working with Dan on, which is how to get one recipe in PyBOMBS to understand other recipe results? In Dan's case, PyBOMBS is installing Ice 3.5.1, but (I'm guessing) Ice 3.4.2 is already installed, and it'll be installed into a place where cmake will find it first. Similarly, your installed system version of libusb will be discovered before a new one installed by PyBOMBS. But we're talking here now about one recipe requiring knowledge of where other recipes installed things. Fixing this is going to take some thought so that we don't over-engineer the solution to one particular problem, setup, or intent. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio