On Fri, May 15, 2015 at 02:58:57PM -0700, Paul Rogers wrote:
> > Near the end of my main build I install parole and xfburn (although
> > I very rarely use the latter) - it looks as if URI is needed,
> > probably for exo, and in a normal build it will already be
> > installed, but I check anyway:
> >
> > test -f /usr/lib/perl5/site_perl/*/URI.pm ||
> > km_build URI ${KM_SCRIPTS}/perl.d/URI
>
> > . ${KM_SCRIPTS}/functions
>
> Umm, at first blush, anything in km_build that'd be useful to me?
> What's in functions?
>
The functions script contains all the things I reference. km_build
gets called with a name (URI in that case) and mostly one other parm
(script name to execute, any parms to pass to that, e.g. the target
name if I'm building blfs-bootscripts. It looks to see if I created
a stamp for this (in which case, the build/install completed) and
if not then it invokes the build using eval, and (a recent change)
invokes a km_failed script for non-zero status, so that even I
cannot overlook that e.g. openssl -j4 failed.More generally, routines for deciding how to untar (nowadays tar copes with everything, but when I started you had to pass -j or -z or whatever) or unzip (and also to handle packages without a directory - mostly zip files, but tzdata is like that). All sorts of infrastructure for logging (I hesitate to say that is now perfect, because I thought that a week ago but then found out that /usr/bin/firefox (a symlink) was not getting handled correctly on an upgrade) and for measuring space and time. The routines for identifying the directory name might give people useful ideas, and I generally use awk and sed : before this, I'd been doing perl stuff to compare a build with the results of building itself, and sometimes I miss that - but generally my perl is very rusty, and in any case my scripts all need to work throughout the build of LFS. Much of it is specific to how I build (/sources is an nfs mount here). And, of course, things to measure space and time (in SBUs) although I would not use those measurements for an edit. So no, it is unlikely to be useful to you. At one time, I used to upload my scripts from time to time, but I don't think anybody was ever interested. And just in case it isn't obvious - my scripts have always been buggy. The important thing is to keep them working well-enough, and to understand the failure modes. So writing your own is encouraged. Some of it is anachronistic (e.g. I start log names with desktop- or general- once I've built the packages I always need, which are in a separate pre-boot script and built from chroot). And I prize verbosity, so that in most cases I can look at the term and see where I am (but for slow packages, knowing the package name is not especially helpful). But am I ashamed of any of the functions ? No, not enough to worry. I'm sure most people don't want to read all 31K, so I'll attach a .xz version. These are designed for my normal urxvt term (100 characters wide), and I deliberately put redundant whitespace in some places, because my .vimrc has "for redundant whitespace, from Jeremy Kerr via Olof Johanson "highlight RedundantWhitespace ctermbg=red guibg=red "match RedundantWhitespace /\s\+$\| \+\ze\t/ highlight RedundantSpaces term=standout ctermbg=red guibg=red match RedundantSpaces /\s\+$\| \+\ze\t/ (found on lkml) and that allows me to use the red markings as an identifier of things I wish to highlight, or for debugging stuff. That works in the term and in urxvt (I think my vim colour scheme is elflord) - I normally use a black background in terms - but on my current experimental built I have real xterm (usually, it's a symlink to urxvt) and there it does not work. ISTR that when I uploaded the earlier versions I labelled them as GPL v2 or later, but the WTFPL would be equally valid (some places do not allow Public Domain). So it's like anything else you find on the web - free to use, maybe sort-of works, and you will need to do the legwork to solve any problems. If anybody is misguided enough to try this, 'template' is what I typically use as the base for a new package. https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Share_and_Enjoy ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.
functions.xz
Description: Binary data
#!/bin/bash
# "standard" template - in practice, this is for everything
# in BLFS
#------------------------------------------------------------------------------
set -e
KM_CURRENT=
KM_PATCHES=
. ${KM_SCRIPTS}/functions
# if 2 args are needed, use checkargs2 $#
# and pass $2 to km_begin
km_checkargs1 $#
test -n "$KM_WHERE"
echo "executing $0 for ${1%%-stamp}"
# notes on this:
# 1. occasionally directory has to remain for another package
# 2. space measurement cannot start until after any rm of previous version
# 3. for now, handle tarballs here - maybe later change to use an
# 'extract' function, particularly for lzma and also for zip files
# but balance against e.g. Mesa - 2 or 3 tarballs for same directory
# 4. using $WHERE saves forgetting enough ../ at the end
cd $KM_WHERE
km_begin
# for a tarball
rm -rf ${KM_DIRECTORY}
tar -x -f ${KM_PACKAGES}/${KM_CURRENT}
cd ${KM_DIRECTORY}
# if no tarball
km_patchit
km_start_SBU
echo "configure"
./configure --prefix=/usr >$KM_LOG 2>&1
echo "make"
make ${MAKEFLAGS} >>$KM_LOG 2>&1
echo "install"
make install >>$KM_LOG 2>&1
cd $KM_WHERE
# hide any static libs,
# do timekeeping, install log, stamp, and clean up
# specify director{y,ies} and/or file(s) to remove from $WHERE
km_finish $KM_DIRECTORY
-- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
