I agree that the information is already there (PETSc makefiles). I think Jed's point was that some people might want to avoid using PETSc's makefile system.
Dmitry On Fri, Apr 23, 2010 at 10:32 AM, Satish Balay <balay at mcs.anl.gov> wrote: > On Fri, 23 Apr 2010, Dmitry Karpeev wrote: > >> On Fri, Apr 23, 2010 at 10:14 AM, Jed Brown <jed at 59a2.org> wrote: >> > On Fri, 23 Apr 2010 10:04:33 -0500, Dmitry Karpeev <karpeev at >> > mcs.anl.gov> wrote: >> >> The users definitely have to decide in the end for themselves, >> >> but they also need to know how the libraries they are about to link >> >> against >> >> were compiled, I think. ?I prefer to give the users more information and >> >> then >> >> let them decide whether to throw it out, rather than give them too little >> >> (I hate being in that position, I know that much). >> > >> > I think we're agreeing, I just don't want them to have to parse a >> > returned command line to isolate parts that they would like separately. >> >> I agree. ?Better to give them both the whole (the command line) and >> the pieces (compiler, flags, etc). > > there are different ways of doing it: > > 1. 'mpicc -show' > > 2. pkgconfig as Jed mentioned > > 3. makefiles - as currently implemented by PETSc. 'make getincludes' > > So we already have a mechanism that provides the relavent > info. Perhaps we need to add more 'make targets' to get the equivalent > of some of this stuff: > >>> > ?CC ?= `petsc-config --c-compiler` > ?CFLAGS += `petsc-config --includes` > ?LDFLAGS += `petsc-config --libs --shared --no-rpath` > << > > Its possible that alternative mechanisms might be useful. But if its > not pkgconfig or petsccc [which some folks might expect] perhaps the > current makefile mechanism is good enough - and a new one is not > needed? > > Satish
