On Thu, 11 Apr 2013, Matthew Knepley wrote: > On Thu, Apr 11, 2013 at 9:48 AM, Satish Balay <balay at mcs.anl.gov> wrote: > > > On Thu, 11 Apr 2013, Matthew Knepley wrote: > > > > > On Thu, Apr 11, 2013 at 9:38 AM, Satish Balay <balay at mcs.anl.gov> > > > wrote: > > > > > > > On Thu, 11 Apr 2013, Matthew Knepley wrote: > > > > > > > > > On Thu, Apr 11, 2013 at 9:17 AM, Satish Balay <balay at mcs.anl.gov> > > wrote: > > > > > > > > > > > On Thu, 11 Apr 2013, Matthew Knepley wrote: > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 7:53 PM, Satish Balay <balay at > > > > > > > mcs.anl.gov > > > > > > > wrote: > > > > > > > > > > > > > > > How do we handle these packages with complicated dependencies > > [they > > > > > > > > are complicated as petsc dependencies?] > > > > > > > > > > > > > > > > In this report hdf5 was built with szip-2.1 and zlib-1.2.7. So > > how > > > > > > > > does petsc configure automatically detect this? > > > > > > > > > > > > > > > > And I've recently used the following for hdf5/necddf5 on fusion > > > > [with > > > > > > > > the extra implicit depenceny of hdf5 on zlib, and netcdf5 on > > hdf5 > > > > from > > > > > > > > within configure] > > > > > > > > > > > > > > > > '--with-hdf5-lib=-L/soft/hdf5/1.8.6-parallel/lib -lhdf5_hl > > > > -lhdf5 > > > > > > > > -lgpfs', > > > > > > > > > > > > > > > > '--with-netcdf-lib=-L/soft/netcdf/4.1.1-parallel/lib > > -lnetcdff > > > > > > > > -lnetcdf -L/usr/kerberos/lib64 -lcurl -ldl -lgssapi_krb5 -lkrb5 > > > > > > -lk5crypto > > > > > > > > -lcom_err -lidn -lssl -lcrypto -lz', > > > > > > > > > > > > > > > > Yeah - things work if the user knows the dependencies and the > > link > > > > > > > > command for those dependencies - and specify it to petsc > > configure > > > > as > > > > > > > > above. But I'm not sure how to autodetect this. > > > > > > > > > > > > > > > > Also currently -lz is handled in package.py with > > > > > > > > 'self.needsCompression' similar to 'self.needsMath' with the > > > > detection > > > > > > > > of -lz in libraires.py:checkCompression() - but one can't > > specify a > > > > > > > > --with-zlib-lib option this way. I guess this part can be > > fixed by > > > > > > > > migrating it a standalone package z.py. [And somehow handle the > > > > > > > > optional part of this dependency for hdf5] > > > > > > > > > > > > > > > > > > > > > We already have a mechanism for this. Lots of packages depend on > > > > > > > other packages. This is just screwed up in the case of libz > > because > > > > > > > someone (maybe me) did not want to write an entire package file > > for > > > > > > > it, and instead copped out with the needsCompression. > > > > > > > > > > > > Currently we handle 'mandatory' dependencies properly - and > > optional > > > > > > >depencencies for --download-pakcage somewhat - but not for > > > > > > --with-package-dir > > > > > > > > > > > > For hdf5 - handling just zlib.py is not sufficient. Do we add > > szip.py, > > > > > > zlib.py, gpfs.py [and perhaps more] for hdf5? And somehow use > > these as > > > > > > optionaly when testing for user provided --with-hdf5? Which package > > > > > > currently implements this usage [to check for this optionaly > > > > > > dependency - and give the correct error]? > > > > > > > > > > > > i.e In this case - when the user specified --with-hdf5-dir option. > > We > > > > > > had to print an error.: > > > > > > * please provide --with-zlib-dir and --with-szip-dir options. > > > > > > [For a different user - with the same usage - there would be no > > error] > > > > > > > > > > > > For netcdf above one would have kerbros.py, curl.py and perhaps > > more? > > > > > > > > > > > > > > > We have had this same discussion a million times, and we always > > > > eventually > > > > > get to the same answer and forget. Do we need our own error message > > for > > > > > petsc-dev? > > > > > > > > > > We cannot possibly guess everything that can go wrong. What we need > > is a > > > > > system > > > > > where the user can specify what he actually wants and we check it. > > So, > > > > zlib > > > > > and > > > > > everything else are optional dependencies for hdf5. If something is > > not > > > > > specified, it > > > > > fails, and the user goes back and specifies the right thing. > > > > > > > > Sure - but specify how? specify everything with > > > > --with-hdf5-lib,--with-hdf5-include options? > > > > > > > > Or somehow he knows that he has to specify > > > > --with-zlib-include/-with-zlib-lib options? > > > > > > > > > > This. It would be nice if HDF5 would tell us about its dependencies, but > > if > > > it does not, then > > > the user has to, and this is our system (packages). > > > > So we would start adding zlib.py, szip.py and manymore [and support > > --download-zlib --download-szip]. And if user gets the error: > > > > --with-hdf5-dir=/foo/bar does not work. > > > > So he/she send us configure.log > > > > Then we look at it and respond saying: you need to specify --with-zlib-dir > > --with-szip-dir options aswell. > > > > Does this look right? > > > Yes, that is what I think makes sense. > > We can always try to add another layer that 'greps' for libz in the hdf5 > error message and guesses that > the user forgot it, but hopefully before we get to it, a sane storage > library appears, or HDF5 gets its act > together.
In this case - why bother with libz.py and szip.py? Why not tell the user to specify hdf5 completely with --with-hdf5-include and --with-hdf5-lib options? Just printing the link errors on the screen might be sufficient to clue in the user. Currently its hidden inside configure. [And its not clear which of the 10 tests configure did for this case should be printed on the screen as the appropriate message] Satish
