On Thu, Nov 1, 2012 at 9:23 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > On Nov 1, 2012, at 7:12 PM, Matthew Knepley <knepley at gmail.com> wrote: > > > On Thu, Nov 1, 2012 at 7:01 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > > Matt, > > > > There are two things. (1) Generating one for a PETSc install that > others can use and (2) using someone else's to build PETSc. to match the > other package (say hypre already built) > > > > I don't see why (1) is a bad idea. > > > > I think this is always a bad idea for the reasons I gave before, namely > that due to the fragility it will > > break frequently, and we will get all the breakage on petsc-maint. > > > > Certainly we will ALL WAYS test any other package we use with PETSc > but can we not use the information in that packages pkgconfig to tell us > what compiler to use etc.? > > > > I am not really against this. However, how would this work? > > We take their information and (try to) use it with a PETSc build, then > we in our configure (as we do know) try to link in their library. You mean this is a "controlling" package, where we take all the info and use it in our configure, instead of a package we are using. Sure that is just another way to input configure options. > > It says one compiler in pkgconfig, but we have > > another from our config. > > There won't be another one in our config since we are building with > their information! > > > Are they the same? There is no simple way to tell. Are they compatible? > Again, no > > simple test. Thus, it would always have to be what the user typed in > already, so what are we saving? > > We are allowing people to (automatically when it works) build a version > of PETSc that matches some package they already have installed. Yes this > doesn't solve all the problems of the world but it is a nice feature. Yes I am not agains this. Matt > > Barry > > > > > Matt > > > > > > Barry > > > > On Nov 1, 2012, at 3:22 PM, Matthew Knepley <knepley at gmail.com> wrote: > > > > > On Thu, Nov 1, 2012 at 3:56 PM, Jed Brown <jedbrown at mcs.anl.gov> > wrote: > > > Bah, the problem with pkgconfig is that it doesn't handle different > versions in different places well. We should use it in most cases, however. > > > > > > I disagree. There is only one way to be certain of a configure > setting, and that is to test it. This will only > > > produce more mail from idiots who move their installation, or copy the > config file, etc. There is no redeeming > > > value in this idea. > > > > > > Matt > > > > > > On Nov 1, 2012 2:41 PM, "Matthew Knepley" <knepley at gmail.com> wrote: > > > On Thu, Nov 1, 2012 at 2:59 PM, Barry Smith <bsmith at mcs.anl.gov> > wrote: > > > > > > Does, should, PETSc generate appropriate pkgconfig information for > itself? Does, can, it use that information from other packages? > > > > > > pkgconfig is too fragile to be of any use. > > > > > > Matt > > > > > > > > > Barry > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121101/c54a5ead/attachment.html>
