[petsc-dev] [petsc-maint #50087] Re: why does PETSc BuildSystem hate me?

[Satish Balay]

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
> > 
> > 
> > 
> > 
> 
> 
>