Barry, I've added code in petsc-dev that warns users of the env variables [does not ask them to unset]. It then ignores these values - and never uses them in configure process.
Wrt Aron's usage: - he is specifying them at command line - which is valid. [also the changes are in petsc-dev - and Arron is using petsc-3.1] Satish On Mon, 26 Jul 2010, Barry Smith wrote: > > On Jul 26, 2010, at 6:48 AM, Aron Ahmadia wrote: > > > Aron, > > We are violently opposed to using environment variables to set configure > options. It is a terrible interface because it is way too easy for people to > screw up, they set some environmental variables in their .login files and > then forget they set them and we waste hours trying to debug what has gone > wrong. We consider the autoconf people to be numbskills for introducing them. > > I want Satish to add code to ./config/configure.py to check for any > environmental variables that are set and tell the user to unset them before > calling ./configure and to remove all uses of them by BuildSystem. For some > reason they still exist in places in BuildSystem and Satish hasn't added code > to reject them. I guess some people like the hassle of ill-defined user > interfaces. > > Matt and Satish, can we finally fix this for once and for all? > > Barry > > > > >>>>> > >>>>>> A > >>>>>> > >>>>>> > >>>>>> On Mon, Jul 26, 2010 at 11:42 AM, Aron Ahmadia < > >>>>>> aron.ahmadia at kaust.edu.sa> wrote: > >>>>>> > >>>>>>> Hey Matt, > >>>>>>> > >>>>>>> It seems to me that when I tell PETSc how to compile/link, it should > >>>>>>> listen. More specifically, if I have set the environment variables > >>>>>>> CC, > >>>>>>> CFLAGS, CXX, CXXFLAGS, LDFLAGS, and FC, and I haven't re-specified > >>>>>>> them in > >>>>>>> configure, they should be respected. > >>>>>>> > >>>>>>> Instead, it goes digging around for an MPI compiler (oh really > >>>>>>> BuildSystem, you know which compiler I want better than I do?) and > >>>>>>> throws > >>>>>>> away my entire environment. So I have to hamfist around it like this: > >>>>>>> > >>>>>>> ./petsc-shaheen-process.py --with-hdf5=1 --with-parmetis=1 > >>>>>>> --prefix=/opt/share/ksl/petsc/3.1.3/ppc450d -CC=$CC -CXX=$CXX -FC=$FC > >>>>>>> --CFLAGS=$CFLAGS --CXXFLAGS=$CXXFLAGS --FFLAGs=$FFLAGS > >>>>>>> --LDFLAGS=$LDFLAGS > >>>>>>> > >>>>>>> It still warns me that it's using environment variables, even when I > >>>>>>> have to shove them down its throat. > >>>>>>> > >>>>>>> I can also take a crack at fixing this myself, unless there's some > >>>>>>> flag for doing this I might be missing. > >>>>>>> > >>>>>>> A > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> What most experimenters take for granted before they begin their > >>>>> experiments is infinitely more interesting than any results to which > >>>>> their > >>>>> experiments lead. > >>>>> -- Norbert Wiener > >>>>> > >>>> > >>>> > >>> > >> > > > > Also, you can see from the configure log that BuildSystem is blatantly > > disregarding the compiler preferences I pass in on the command line. > > > > A > > > > On Mon, Jul 26, 2010 at 12:27 PM, Aron Ahmadia <aron.ahmadia at > > kaust.edu.sa> wrote: > > This is the blas-lapack not being detected: > > > > aron at fen1:~/process/installs/builddir_ppc64/petsc-3.1-p3.bgp> printenv > > LDFLAGS > > -L/opt/share/ksl/zlib/1.2.5/ppc450d/lib > > -R/opt/share/ksl/zlib/1.2.5/ppc450d/lib -lz -lz > > -L/opt/share/ksl/hdf5/1.8.5/ppc450d/lib -lhdf5_fortran -lhdf5 > > -lhdf5hl_fortran -lhdf5_hl -L/opt/share/ksl/parmetis/3.1.1/ppc450d/lib > > -lparmetis -lmetis -L/opt/share/ksl/blas/pdc/ppc450d/lib -lblas > > -L/opt/share/ksl/blas/pdc/ppc450d/lib -lblas > > -L/opt/share/ksl/lapack/pdc/ppc450d/lib -llapack > > > > ./petsc-shaheen-process.py --with-hdf5=1 --with-parmetis=1 > > --prefix=/opt/share/ksl/petsc/3.1.3/ppc450d -CC=$CC -CXX=$CXX -FC=$FC > > --CFLAGS=$CFLAGS --CXXFLAGS=$CXXFLAGS --FFLAGs=$FFLAGS --LDFLAGS=$LDFLAGS > > --with-hdf5-dir=/opt/share/ksl/hdf5/1.8.5/ppc450d/ > > --with-parmetis-dir=/opt/share/ksl/parmetis/3.1.1/ppc450d/ > > > > A > > > > On Mon, Jul 26, 2010 at 12:18 PM, Aron Ahmadia <aron.ahmadia at > > kaust.edu.sa> wrote: > > can I pass in a list of directories for buildsystem to put on the path when > > I specify hdf5-dir? For whatever reason buildsystem is keeping the > > libraries I specified in ldflags but throwing away my search paths... > > > > A > > > > > > On Mon, Jul 26, 2010 at 12:17 PM, Aron Ahmadia <aron.ahmadia at > > kaust.edu.sa> wrote: > > I'll send you the configure log. It's not doing that. Now I can't get it > > to detect HDF5 with z-lib compression because it throws away my LDFLAGS > > when it tries to build hdf5 which requires libz to be on the library path. > > > > A > > > > > > On Mon, Jul 26, 2010 at 12:08 PM, Matthew Knepley <knepley at gmail.com> > > wrote: > > On Mon, Jul 26, 2010 at 6:50 PM, Aron Ahmadia <aron.ahmadia at > > kaust.edu.sa> wrote: > > Also, it doesn't check to see if the blas/lapack are already available > > through the user's environment, it immediately starts popping on random > > libraries... > > > > I do not understand what you mean by "available through the user env". It > > definitely checks for BLAS/LAPACK > > with no args first (other than -lblas -llapack). > > > > Matt > > > > A > > > > > > On Mon, Jul 26, 2010 at 11:42 AM, Aron Ahmadia <aron.ahmadia at > > kaust.edu.sa> wrote: > > Hey Matt, > > > > It seems to me that when I tell PETSc how to compile/link, it should > > listen. More specifically, if I have set the environment variables CC, > > CFLAGS, CXX, CXXFLAGS, LDFLAGS, and FC, and I haven't re-specified them in > > configure, they should be respected. > > > > Instead, it goes digging around for an MPI compiler (oh really BuildSystem, > > you know which compiler I want better than I do?) and throws away my entire > > environment. So I have to hamfist around it like this: > > > > ./petsc-shaheen-process.py --with-hdf5=1 --with-parmetis=1 > > --prefix=/opt/share/ksl/petsc/3.1.3/ppc450d -CC=$CC -CXX=$CXX -FC=$FC > > --CFLAGS=$CFLAGS --CXXFLAGS=$CXXFLAGS --FFLAGs=$FFLAGS --LDFLAGS=$LDFLAGS > > > > It still warns me that it's using environment variables, even when I have > > to shove them down its throat. > > > > I can also take a crack at fixing this myself, unless there's some flag for > > doing this I might be missing. > > > > A > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > > experiments is infinitely more interesting than any results to which their > > experiments lead. > > -- Norbert Wiener > > > > > > > > > > >
