On 01/23/2019 10:01 PM, Ken Moffat via blfs-dev wrote:
On Wed, Jan 23, 2019 at 09:06:21PM -0600, Bruce Dubbs via blfs-dev wrote:
On 01/23/2019 08:15 PM, Ken Moffat via blfs-dev wrote:
/opt/something is fine for testing. /opt/rust-version would be
better (and allow the old version to be kept - just fix PATH up
manually and use one for building old versions, another for building
current and development) - see what you put in the librsvg ticket re
their changelog.
It might come to that, but for the moment I prefer to just have one
in the book, and to ensure that what we have works for all the
packages which need it. The extended testing is how I came up with
my current .sig.
I suggest
/opt/rustc-1.x.y
/opt/rustc -> rustc-1.x.y
Using this, the user has to only add /opt/rustc/lib to /etc/ld.so.conf and
to add /opt/rustc/bin to the PATH. Then if there are multiple versions of
rustc installed, reverting to an earlier version is only a simple change to
a symlink.
Thinking about this, but although it sounds obvious I'm not keen to
include it in the current update. I don't use LFS's extensive path
manipulations, and if people _need_ to use an older version (e.g.
when building something external and finding it has broken) then
they need to know which version they are using.
I would not be against 'export PATH=/opt/rustc' at the start of rust
packages (and corresponding unset at the end). But my scripts are
close to what is in the current book, when necessary I specify PATH
in various places. Crucially, I have not tested this suggested
change.
It will also need some boilerplate for the /opt/rustc symlink and
the /etc/ld.so.conf lines.
I will create a demo version of what I am talking about after you make
the rustc update. I'll also send you my build script for comparison/review.
It also makes it easy to remove a test installation without polluting /usr.
I note that rustc-1.32.0-src/install is 716M. On my system right now
~/.cargo is 747M so this package has the largest installed footprint of any
295M /home/lfs/.cargo
295M /home/ken/.cargo
294M /home/ken/.cargo-base1331
295M /home/ken/.cargo-base1320
I was testing all the packages which use rust, to see how much (if
anything) they downloaded. Here, user lfs does the automated
installs but I do a lot of test builds manually.
Seems the logical thing to do.
So, I wipe out .cargo before a new build. This also lets me test
how long is spent downloading cargo files by rust - only a minute or
so with a decent network connection, in SBU terms it is lost in the
rounding.
I thought about that. I'll test it that way.
Only cbindgen seems to currently download cargo files not provided
by rustc-1.32.0, and the amount is not large. I suppose it is
possible that current firefox stable (64.0.2) might need a few older
system cargo files.
BLFS package (libreoffice is 756M, OpenJDK is 770M, kf5 is 740M; I'm not
sure about a complete texlive install).
I think I normally build a bit less of libreoffice than what is in
the book, but a lot more languages on this particular machine so I
have got 2.0G. For 6.1.2.1 on another machine I have only 567M so
yes, the book's version is smaller than current rustc. With shipped
LLVM and without the (html) docs, the install is 475M, or 789M with
the docs.
Full TeXLive from source is 5.4G (plus whatever went into /usr for
the extra packages).
And I though I was the one who worried about disk space ;-)
Worried? No. But I do pay attention. My default LFS partition size in
the past has been 10G with separate partitions for /tmp, /home, /opt,
/boot, but I am finding that building everything in BLFS makes things
too tight for space. For my next full build, I will use larger partitions.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
