[petsc-dev] damn symlinks on windows

[Satish Balay]

There is a chicken & egg problem here.

Configure determines PETSC_ARCH [and hence
PETSC_ARCH/conf/configure.log location] a bit further down in the
configure process. And this location can change depending on how the
dependencies get evaluated.

Also - the log is more of a static value on the buildsystem side and
at the very end - configure.log gets moved over to
PETSC_ARCH/conf/petscvariables [I'm not sure exactly who does this]

So if we want to have a truly multiple build support - we can't still
stick to the old 'have multiple PETSC_ARCHes in PETSC_DIR mode' - but
something like autoconf/automake where one would do:

mkdir objdir
cd objdir
../configure
make
make install.

For some reason the current mode still works for parallel builds
[perhaps because of the way when we overwrite files - filedescriptiors
are still preserved?].

There are other parts of configure which probably still stomp on each
other [like etags, fortranstub generators invoked within configure?]

Satish

On Wed, 9 Oct 2013, Jed Brown wrote:

> Aron Ahmadia <aron at ahmadia.net> writes:
> 
> > 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 would like to always gziping the results to keep our mailing list data
> volume down.
> 
> > 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.
> 
> > but the symbolic links are both unexpected and confusing to beginners.
> 
> Well, symbolic links work properly on real operating systems. ;-)
>