[petsc-dev] Symbol visibility

[Barry Smith]

On Dec 6, 2010, at 1:02 PM, Jed Brown wrote:

> On Mon, Dec 6, 2010 at 19:53, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Worse comes to worse I put it back (but better next time :-).
> 
> Apparently this can done purely with headers (no need to touch all the source files) and (uglier in my opinion, but still possible) with a pragma to push and pop the visibility state (C99 at least has _Pragma, it's dirtier to need #pragma (of course wrapped based on a configure test)).  This makes it a much simpler issue to "put back, but better" if needed.
>  
>  Actually I think handling these "things" with CPP is not the way to go, in fact, I'd like to see, if possible, almost no use of CPP in PETSc source. Reason: PETSc source code currently is the combination of two relatively simple but very different, languages CPP and C. Doing source to source manipulations on this beast is a nightmare because one cannot even parse CPP plus C. If we eliminate the CPP then it becomes only C which we parse and manipulate relatively easily, this opens up enormous opportunities for a whole new approach to code development we do not have currently and cannot have with a CPP plus C code base. Of course, I could be totally on the wrong track but I won't know without investigation.
> 
> Clang/LLVM can parse the C with everything in it, then give you the AST or whatever intermediate form you like.

  Nonsense!  Clang/LLVM preprocesses the CPP directives out and gives you the AST for the resulting C code. This is definitely not what we want because we cannot even go back from this form to the original code, and the first thing I want with any source to source translator is the identity operator.  Now if I am wrong and Clang/LLVM does preserve all the CPP constructs (which I believe is pretty much impossible) then that is FANTASTIC and we are half-way to nirvana already and we can laden PETSc with as many complicated CPP macros as we want :-). Please tell me I am wrong.

  
> 
>  Honestly I am sick of having this big code base where making changes means editing flat files and manually changing source code, I thinking that model really needs to change. I don't really know how to change the model but I really want to see if change and if that involves going down some wrong roads that is ok with me, better than not trying things.
> 
> Sounds like you should switch to Smalltalk.

   I want a language that people actually use and that plays well with other languages but I want the advantage of languages that support more than the edit file--run compiler paradigm and if no one else wants to develop that then we need to develop it.

   Barry

> 
> Jed