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. > 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. 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. 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 ;-) ĸen -- thread 'main' panicked at 'giraffe', /tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
