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
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
