On Nov 1, 2012, at 8:28 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 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.
Yup that is all it is.
>
> > 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
