When I first started to use libreoffice I think the book mentioned
about saving the "non-optional" downloads that it does at the start
of 'make', such as
0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz
and
libvisio-0.0.31.tar.bz2
with 4.2.3.3 and my current config settings.
Sometime, perhaps when the build system was overhauled, that fell
out.
Alternatively, maybe I'm imagining that it was ever in the book,
and _I_ dropped it from my scripts because I could not immediately
see how to apply it after things had changed.
Anyway, my downloads are now fast-enough and re-downloading these
files on every build is not going to cause me any trouble. Except,
it has now twice broken my builds because dev-www.libreoffice.org
sometimes disappears in the small hours (British time). The second
time was earlier this week : I got up in the small hours, checked
the build and found it had halted because of a typo I had made when
I altered my script to better match the current book.
Fixed that, the next 3 attempts failed because that site was not
responding. Waited a bit, tried pinging it, no packets returned.
Tried again at about 08:30 British time, still no response. Tried
again some hours later, it was back and I was able to procede.
While it was building I thought about this and decided to try
copying the downloads, and then restoring them on the next build.
Tonight I'm now running my next build and it didn't do any downloads
;-) src/fetch.log just has one line:
Wed 21 May 23:47:32 BST 2014
whereas the first fetch.log has 343 lines for about 30 downloads,
and 'make' is now building it.
What I have is :
1. Before 'make build', if the directory with the downloads exists
locally, [ /sources/libreoffice-W.X.Y.Z-downloads for me ]
cp -v /path/to/directory/* src
rm -vf src/fetch.log
2. after 'make build', if that direcotry does NOT exist
mkdir -pv /path/to/directory
DOWNLOADS=$(ls /scratch/working/libreoffice-4.2.3.3/src/ \
| grep -v libreoffice | grep -v tmp)
cp -v $DOWNLOADS /path/to/directory
I actually call this variable KM_DOWNLOADS, to put it in a KM_
namespace so that it doesn't interfere with the build (I had a lot
of grief with bison when that started to use a variable name I was
setting in my script). The book doesn't do scripts for most
packages, so I guess something like downloads= ... unset downloads
would be fine.
I hope this is useful to someone who has the same issue, but I
guess that many users only build a version once. I suppose some
people might have download caps, or slowness. I'm fairly sure
that it might break if you rebuild the same version but with a
different set of autogen options.
So, is it worth adding this to the LO page ?
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
