Moving to PETSc dev for more input

    Lisandro,

       I understand the rational for not wanting it on by default for random 
user code but the fact is that is is NEEDED to compile the PETSc source (and 
examples) and so seems wrong that those configurations can only be built if the 
user provides this obscure flag PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND they 
won't know about.

      We could have it on by default and have a flag 
PETSC_SKIP_CXX_COMPLEX_FLOAT_WORKAROUND that users put in before they include 
any PETSc includes but I suspect you won't like this? 

      Somehow have the gnu make system pass in the flag 
PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND when compiling PETSc source and examples 
but not other code? How to organize that?

       Define PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND at the top of every PETSc 
source file that needs it (and examples that need it)? Ugly, but doable? 

       "Fix" the PETSc source code so the issues it handles don't come up? Or 
reduce them and stick the PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND just in the 
troublesome files?

      Any other way to have it on when needed but off otherwise?

  Barry




> On Apr 17, 2019, at 7:27 AM, Lisandro Dalcin <[email protected]> wrote:
> 
> 
> 
> On Wed, 17 Apr 2019 at 10:45, Smith, Barry F. <[email protected]> wrote:
> 
> I admit I don't understand why it is implemented this. That is why it isn't 
> turned on automatically in this situation; perhaps it breaks on some systems. 
> I would like to move it to be automatic if possible.
> 
> 
> Barry, I decided to not turn it on by default because the workaround relies 
> on injecting a lot of non-standard operators between complex and other types 
> in the global namespace. This may interact really bad with user code or other 
> library header files defining these exact same operators for whatever reason. 
> So better safe than sorry, it is users responsibility, either using a -D 
> flag, or even:
> 
> // somesource.cxx
> #define PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND
> #include <petsc.h>
> 
> 
> PS: Maybe we should add all these definitions in a new header, let say 
> "petscmathcomplex.h", so that users can explicitly #include it in their code 
> at their own responsibility. This header will not have any effects for 
> non-C++ non-complex builds (we may decide the fine details later), and then 
> "petscmath.h" just include this file if 
> PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND is #defined.
> 
> 
> -- 
> Lisandro Dalcin
> ============
> Research Scientist
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/

Reply via email to