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
extra-font-analysis.sh
Description: Bourne shell script
#!/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
-- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
