add cmake support for mmg and parmmg as submodules/projects

[prudhomm]

in Feelpp, mmg and parmmg are integrated as sumodules. this case is not addressed by parmmg when it looks for mmg. use modern cmake it is very easy to pass the full configuration of mmg to parmmg in order to compile with the right flags If that's ok for you to have something like that, I can provide the changes I made to parmmg

[prj-]

I think this is redundant with issue https://github.com/MmgTools/ParMmg/issues/5, isn't it? I'm trying to get Luca and Algiane to accept a slight adaptation of the compilation process I made so that it's easier to compile ParMmg, without needing to set MMG_BUILDDIR. In the end, the aim is to have a seamless integration in PETSc, cf. MR #3375. The changes are in https://github.com/MmgTools/ParMmg/pull/27 but you need specific Mmg and ParMmg forks. Hopefully these changes will simplify the use of submodules as well.

[lcirrottola]

Hello, We are indeed considering all the pros and cons of different modifications to the way ParMmg looks for Mmg, in order to ease the integration in external projects.

Feel free to share your solution if it works for you, thanks, it is helpful also to understand your specific needs.

Here I resume the requirement that we have listed until now.

1. ParMmg should build both with a user-provided or an embedded versions of Mmg.
2. The embedded Mmg version should be downloaded during configuration and not during build.
3. The compatibility of the user-provided Mmg version should be explicitly checked during build. 3.1. An error should be raised if the version is not compatible. 3.2. A warning if compatibility cannot be checked.
4. The possibility not to build any library should be preserved.
5. All Mmg headers required by ParMmg should be accessible from the same path (instead of two separate MMG_BUILDDIR and MMG_DIR paths), but 5.1 All additional headers required by ParMmg should be separate from the officially supported Mmg headers (so that they can be understood as private with no ambiguity).

Feel free to contribute with any additional feature I have not mentioned. Thanks! Luca

[prudhomm]

Hi @lcirrottola @prj- here are a few patches I did:

• fix linking with clang and gcc > 10 https://github.com/feelpp/ParMmg/commit/875ea5ce5a86e001d24a52ee042c259cb27ac85a
• add target_include_directories when mmg is a submodule of a super project https://github.com/feelpp/ParMmg/commit/1f7a5c7b43947c5e9d3708661888238acbc3fbaf
• use projet name https://github.com/feelpp/ParMmg/commit/a07eeae0b16c9fbedb43c846efc2ec36b3cf43ff
• fix name to avoid conflict between mmg and parmmg https://github.com/feelpp/ParMmg/commit/b5a85183038210dabc7f0cd83b4bd36865754610

with this I have mmg and parmmg as submodules of feelpp, it compiles and runs although the remeshing still crashes. The patches are not satisfactory for consumption but I can certainly modify https://github.com/feelpp/ParMmg/commit/1f7a5c7b43947c5e9d3708661888238acbc3fbaf to make it cleaner for inclusion in parmmg

by the way I used the cantor pairing function to generate the global ids for the faces at the interfaces applied to the ids of the vertices face. it seems to work quite well on the simple example I work with currently

[lcirrottola]

Thanks @prudhomm! (I comment on the faces API here https://github.com/MmgTools/ParMmg/issues/30#issuecomment-746745138 for easier tracking)