On Mar 5, 2013, at 6:24 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Tue, Mar 5, 2013 at 6:02 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > We have --with-clanguage=c or c++ (this is already weird, most packages > don't strife to be built either with C or C++) > --with-c-support=0,1 (compile with C++ but with > C bindings so C application can use it) > > User Code PETSc compiled with > ------------------------ C C++ > C x x > C++ x x > > Hope back into Satish's way back machine and ask the question > "why do we have this c-support business"? Seems like it complicates > life a lot? > > I would just unconditionally use extern "C" when compiling PETSc with a C++ > compiler. Ok, and this will still support all four cases above. How do we do that? And would it simplify the mess we have now? > We don't use overloading (PetscPolymorphic* was removed last spring) so I > don't think there is any functional reason to mangle symbols. AFAICT, the > only functional reason for building PETSc with a C++ compiler is to use C++ > complex Yes, if a C++ programmer is using PETSc and complex numbers this is a legitimate case > (and perhaps because the C++ compiler catches different errors than the C > compiler). Yes, this is a legitimate use of our testing PETSc regularly with C++. Barry
