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 <[email protected]> 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. ;-) >
