Hey,
>> I don't understand why you guys create a symbolic link to the
configure.log in the base directory. This has always confused me, and
I'm pretty sure I've accidentally sent a symbolic link or two from OS
X at one point or another. I think you should gzip and cp the
configure.log over as part of a successful install, and leave it
sitting in the main directory otherwise.
I think configure.log should always be created in
$PETSC_ARCH/conf/configure.log. It can be symlinked or copied to the
root directory at some later time, but creating it in the root directory
is an unnecessary race between multiple configure processes.
I agree on the race condition, even though creating a symlink is
strictly speaking still not 100% robust with respect to race conditions.
For the reasons Jed mentioned, configure.log should reside somewhere
underneath $PETSC_ARCH in order to be able to deal with multiple
configurations. What about the following:
1.) copy configure.log
from $PETSC_ARCH/conf/ to $PETSC_DIR/configure-$PETSC_ARCH.log
2.) rename $PETSC_DIR/configure.log to
$PETSC_DIR/configure-$PETSC_ARCH-to-delete.log
3.) rename $PETSC_DIR/configure-$PETSC_ARCH.log to
$PETSC_DIR/configure.log
4.) delete $PETSC_DIR/configure-$PETSC_ARCH-to-delete.log
Clearly, 1.) works well even when configuring multiple ARCHes
simultaneously. Sine file renaming is a fast operation, 2.)-4.) can be
considered almost as robust (or fragile) as the current approach using
symlinks. Moreover, it also works on broken OSes without assuming a
certain filesystem.
I would like to always gziping the results to keep our mailing list data
volume down.
Do we have a reasonably portable facility for gzipping available via
BuildSystem/Python? If so, run the zipping process between 1.) and 2.)
above.
Advanced users may want to have the ability to have configure.log
generated elsewhere (and you could make this a configure argument if
you really felt like it),
Actually, this would be useful because it would allow building a custom
version of PETSc without having write access to the directory containing
the source code. So for example, you could create a new PETSC_ARCH from
a system-wide copy of the source code without needing to copy it to your
home directory first.
I thought the existing procedure of 'trying' to create the symlink is
sufficiently robust and allows for such a setting already? Likewise,
what about creating the symlink/copy in the current working directory if
writing to $PETSC_DIR fails?
Best regards,
Karli
