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).
On Fri, Apr 23, 2010 at 10:00 AM, Jed Brown <jed at 59a2.org> wrote: > On Fri, 23 Apr 2010 09:40:16 -0500, Dmitry Karpeev <karpeev at mcs.anl.gov> > wrote: >> I would just add that petsc-config should, in my opinion, define >> compile and link commands (i.e., including the compiler and the linker), >> not merely the relevant flags (some of those are compiler-dependent). > > Yes, the compiler needs to be available, but in the end, it's up to the > user whether to use the same compiler or try a different one. ?To be > clear, I'm not alone in hating wrapper compilers and want nothing to do > with petscCC or something of that form. ?But I think it is desirable for > users to have > > ?CC ?= `petsc-config --c-compiler` > ?CFLAGS += `petsc-config --includes` > ?LDFLAGS += `petsc-config --libs --shared --no-rpath` > > readily available in whatever build system they like. > > Jed >
