Closed schnellerhase closed 3 months ago
Looks good - could you add has_ptscotch
? (The compiler definition is HAS_PTSCOTCH
.)
Seems we had a bug before with the missing definition. SCOTCH was required, but now it's optional, something must have got lost in that change.
I am unsure about what to do with the std::string
's. The tested compilers do not seem to have implemented compile time strings yet, so we need to treat them differently.
I tested inline
, instead of the consteval
which works. Besides that I tried the use of std::string_view
which I am unsure is a legal use of such to be honest. Do you have any thoughts on that?
We tend not to manually inline things - let the compiler use its cost model (these are almost certainly already inlined already).
We need either an inline
or a consteval
to allow for the now multiple definitions in the different compile units. The real in lining of the compiler I do not want to manipulate.
Compile time strings still looks complex in C++20 - just keep those routines as they are.
Compile time strings still looks complex in C++20 - just keep those routines as they are.
In the sense of the current state, or returning them to the previous compiled setting of before?
Can you keep constexpr in the header and keep the string ones in the .cpp?
You should generally avoid using force pushes when working on shared projects.
Could you also add a new wrapper for DOLFINX_STDC_NO_COMPLEX_KERNELS? e.g. has_complex_kernels?
Alright, will refrain from it, just worked with projects that had a linear history before.
I can't seem to find the option DOLFINX_STDC_NO_COMPLEX_KERNELS
, can you point me to its definition?
You need to merge origin/main
@schnellerhase could you make sure these are allwrapped into Python in another PR? Also good practice. Thanks.
@schnellerhase could you make sure these are allwrapped into Python in another PR? Also good practice. Thanks.
Got lost somehow, sorry - now done in a PR.
Resolves #3