Re: ALFS

On Thu, May 09, 2013 at 09:38:03AM -0400, public wrote:
> Would SOMEONE mind actually give me some REAL help on FINALLY
> writing an automation tool for LFS/BLFS This hand coding SUCKS and I've 
> done it SEVERAL times.
> I tried to ask about this ages ago and NOONE had any useful response. 
> Yes there is JHALFS but anyone would have to agree it's more than bit 
> flawed. I USED be an embedded level C coder of fair to middling talent 
> and would LOVE to REALLY fix the situation.
> 
> any takers???????
> 
 I don't have an automation _tool_, but I do automate my builds.  My
scripts are all in bash and use an extensive number of functions to
do the repetitive bit.  So, for me adding a new package in my
desktop is typically :

1. Try to run configure, by hand, on a completed system.  Sometimes
this shows missing dependencies - if I've willing to try them,
repeat.  If it configures ok, build and try a DESTDIR install.  Tune
the options.

2. Create an "extra-" script from my templates, build and install.
See if I find the package useful [ occasionally, this shows that I need
to do more research, and perhaps add other dependencies ].

3. If I do find it useful, look at the dependencies to take a view on
where I can build it (most new additions don't bring anything for my
existing packages, but occasionally I have to add a dependency and
realise it could be used by an existing package).  Integrate the
scripts into the build in a developmant branch, and test if it is ok
when I next build a new desktop.

 For existing BLFS package version updates, I sometimes miss minor
changes in the instructions because I'm just reading the rendered text
instead of looking at the individual svn changes.  So far, that hasn't
been catastrophic - if the build fails, it's easy to spot the problem.
If it builds but affects the boot (e.g. different directory, or user,
is now referenced) it's usually easy enough to sort that out.

 However, I don't agree with your description of jhalfs as flawed -
I only used it when I was trying to test the cross-compile-for-alpha
instructions in cross-lfs, and never managed to get very far (too
much of that architecture was broken at that time).  It certainly
doesn't suit my way of working (/sources is an nfs mount, I do _not_
want to build there, and as an editor I prefer to build/adjust
the instructions before I update the xml), but many people seem to
manage.

 No system is perfect, but I think a productive approach is to
create on set of scripts or programs, then stick with that approach
for soem time while you learn what could be done better, and also
how it fails (so that you will learn where to look when you get a
problem - I still haven't fully got to grips with my recent move to
'set -e' : was able to remove a lot of specific status checking, but
occasionally things don't stop where I think they will after an
error.

 On my latest desktop I've still got 2 or 3 package issues, and I've
become aware of a major error in my calculation of space (except in
/tools!), but the completed system is working ok.  The point is to
create a tool which is good enough to use.

 Attached examples are a "driver" script (for ttf/otf font analysis),
which pulls in all my functions, and a general package template : I
highlight trailing whitespace, so that I can see which lines usually
need to be changed.  No point attaching anything else, but if anyone
cares they can find my *old* (November 2011) buildscripts at
http://www.linuxfromscratch.org/~ken/desktop-builds/

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

#!/bin/bash
# I have (one) useful perl script from Font::TTF::Scripts, ttf2config.pl,
# which I use for working out what a font covers.  It needs Font::TTF
# which requires IO::String.  Contains 'fret' which requires Text::PDF
# at runtime.  Fontforge appears to be able to extract ttf files from ttc.
#------------------------------------------------------------------
set -e
# STAGE will be general-something or desktopN
export STAGE=desktop-extra

# work out where the script lives, to find its directory, and hence its clients
# strip off last '/' and the following name
SCRIPTS=${0%/*}
echo "will look for client scripts in $SCRIPTS"

. /misc/packages

#make the functions script noisy to report what it will do
VERBOSE=verbose
. ${SCRIPTS}/functions
# and quieten it for the rest of the build
unset VERBOSE

# start timing now that the functions have been read
set_start

. /misc/hostfile

CFLAGS='-O2'
CXXFLAGS='-O2'
export CFLAGS CXXFLAGS LDFLAGS

# set $ARCH to ppc if appropriate, for ppc (endian) patches
ARCH=`uname -m`

test -n "$HOST"

# prefer to build in /scratch, if possible
echo "testing if /scratch/working exists"
if [ -d /scratch ]; then
	if ! [ -d /scratch/working ]; then
		echo "please mount or create /scratch/working"
		exit 2
	else
		WHERE=/scratch/working
	fi
else
	WHERE=/usr/src
fi

# need to export variables here
export ARCH BOX HOST LOGDIRECTORY SCRIPTS WHERE

mkdir -pv $LOGDIR

build	IO-String		${SCRIPTS}/extra.d/IO-String &&

build	Font-TTF		${SCRIPTS}/extra.d/Font-TTF &&

build	Font-TTF-Scripts	${SCRIPTS}/extra.d/Font-TTF-Scripts &&

build	Text-PDF		${SCRIPTS}/extra.d/Text-PDF &&

build	fontforge		${SCRIPTS}/extra.d/fontforge

driverscript_timings

#!/bin/bash

# "standard" template - in practice, this is for everything
# in BLFS
#------------------------------------------------------------------------------
set -e

CURRENT=
PATCHES=

. ${SCRIPTS}/functions

# if 2 args are needed, use checkargs2 $#	
# and pass $2 to begin |begin_for_destdir
checkargs1 $#	

test -n "$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 $WHERE
begin

# for a tarball	
rm -rf ${DIRECTORY}
tar -x -f ${PACKAGES}/${CURRENT}
cd ${DIRECTORY}
	
# if no tarball	
	
patchit
start_SBU

echo "configure"
./configure --prefix=/usr  >$LOG 2>&1

echo "make"
make ${MAKEFLAGS} >>$LOG 2>&1

echo "install"
make install >>$LOG 2>&1

cd $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
finish $DIRECTORY