Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]

Dan McGhee beesnees62 at att.net
Sat Mar 12 16:00:56 PST 2011


What might make this OT is that it's not a question specifically about 
building LFS, but rather a question of a script that I use to build LFS 
not working the way I want it to.  If this is really OT, maybe someone 
will respond privately if the any have any ideas.

As many of you know, I use the "More Control with Package Users" 
management system.  I have  modified the build scripts in the hint to 
minimize the pedantic work at the keyboard that's involved with a 
build.  The script is designed to find the tarball, un-tar it and the 
configure, make,make check and install.  Additionally, I add other 
necessary commands from the book in the appropriate places; e.g.  
patches, creating symlinks and moving files around.

The script has evolved over six years and, much to my chagrin right now, 
I've not been good at keeping the old versions or maintaining a changelog.

One thing I want it to do is recover from a failed 'make' or 'install' 
without have to run the whole script again.  This feature *used to* 
work.  It now doesn't.  If everything is OK, the script runs from the 
beginning to the successful end of a build.  But if there is a "glitch," 
the recovery doesn't happen.

The most common interruption in a build, when using more control, is 
write permissions to a directory.  This causes the 'install' to abort.  
The fix is simple.  Change the write permissions and re-run the script.  
I want it to "pick up" with the "make install" command, but right now it 
goes to the "make" command on any abort.  I thing the testing for 
conditions is failing, and I cannot see the flaw in the logic or 
construction.  It is in this area that I'd like some help.  A fresh set 
of eyes, so to speak.

Following is the script from the "variable definition" through the logic 
tests.  I've eliminated all the "extra" stuff.

#! /bin/bash

# Begin Build for <PACKAGE>

# Run this script from the package user's home directory by invoking it
# with the package name--ex. vim-7.2. <./build vim-7.2 or ./build 
$(whoami)> It will find
# the tarball in $PACKAGES, untar it, change to the created directory
# and "configure, make, make check and make install."  Then it will 
"clean up"
# by creating a list of the installed files and remove the source tree.

# It will create 6 log files in the $HOME directory:
#   configure.log: All messages output during configure
#   configure.err: Just the errors output during configure
#   make.log: All messages output during make
#   make.err: Just the errors output during make
#   install.log: All messages output during make install
#   install.err: Just the errors output during make install

# variables
package=$@
logdir=$package-logs
PACKAGES=/sources
CURRENT=$package

<took out a lot of stuff>
# Begin tests and function calls for fresh and failed builds.

# This one recovers from failed "make."
if [ -e $logdir/make-`echo $package`.err ] && \
[ ! -e $logdir/install-`echo $package`.err ]; then      #Now build

<removed "make," "make check" and "make install" sections>
fi

# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] && \
[ ! -e $HOME/$package-files.list ]; then

<removed "make install" section>

fi

# This one does everything through configure, make, make install
if [ ! -e $logdir ];  then

<removed "configure, make, make check and make install" sections>

<removed extra commands and "clean up" sections.>
fi


# End Build

This script creates six logs: configure.{log,err}, make.{log,err} and 
install.{log,err}, which I put in a log directory, $logdir.  The very 
last thing is does is create a list of files installed, 
<$package-files.list>.  Therefore, and here comes the testing logic, at 
the beginning there is no log directory, and  the test becomes [ ! -e 
$logdir ].

The necessary and sufficient conditions to define a failed make are a 
make log or configure log that exists and an install log or package file 
list that does not exist.  If an install fails, there will be a "make" 
log but no file list.  An install log *may* exist so I don't consider it 
in the logic.

The preceding two paragraphs are my logic.  Would someone please, using 
that, compare the logic to the test statements to see if they match, if 
the tests are constructed properly or if I need different logic.

As I said, if all is well, the script runs like a charm.  If there's a 
hiccup, a failed "install," the script starts from the "make" test.  
Doesn't that mean the the logic failed?

I've removed a lot of stuff in the script trying to make things relevant 
and specific to only the question.  Please feel free to ask for 
additional info.

I'm hoping that someone can point me to better constructs or better logic.

Thanks,
Dan



More information about the lfs-support mailing list