[petsc-dev] Compiling C code with C compiler

[Barry Smith]

   Jed,

     If it is as simple as you say then I am fine with adding support BUT it will require "yet another flag" and hence increase complexity. --with-c-for-c-code=1 or something and either require a compiler that is smart enough to switch based on extension or two lists of files to compile with the two compilers. These choices are already complicated for some users and the logic in PETSc will get messy.

    Barry

On Apr 5, 2011, at 2:03 AM, Jed Brown wrote:

> On Tue, Apr 5, 2011 at 04:33, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Since the sieve c++ compiled code uses the C code (like VecXXX) the C++ compiler would have to know that the other parts of C are not compiled with C++. At a minimum you would have to extern c it in the header files other wise the C++ compiled code will call the C routines with name-mangling turned on while the C compiler doesn't know about name mangling and hence would generate routines without name mangling and the c++ code wouldn't find the c routines.
> 
> But this is already what happens --with-c-support. Why is it ever necessary to compile the C source with a C++ compiler (that is, why support with-c-support=0)? The C++ convenience functions (PetscPolymorphicFunction) can easily be defined whenever a C++ compiler is used, they will be name mangled (and usually inlined). I think all you would need to do is remove the PETSC_USE_EXTERN_CXX clause from
> 
> #if !defined(PETSC_USE_EXTERN_CXX) && defined(__cplusplus)
>  
> In other words, even without issues of struct layouts currently everything in PETSc needs to be built with the same compiler. If sieve was made a completely separate package form PETSc then one could easily arrange things so that sieve compiled with c++ and PETSc with c.
> 
> I don't see any complexity in always building C source with a C compiler and C++ source with a C++ compiler. It seems simpler to me. And then people could build a PETSc that includes Sieve and still call it from C (e.g. when they happen to not be using Sieve).
> 
> 
> The only problem I can think of, and which might be justification for building C code with a C++ compiler, is that C++ compilers seem to be stricter about complex. C99 complex is binary compatible with C++ complex, but type checking is weaker. I don't know if this is implicit in the standard or if the GNU compilers are unnecessarily lenient about C99 complex. This is purely a matter of quality error/warning messages, but I'm loathe to give up any static type checking.