[petsc-dev] damn symlinks on windows

[Karl Rupp]

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