Should there be a global mmgcmakedefines.h for all three?

Developers Help
#1

Not sure if I messed something up but it seems to me that after building the “INSTALL” target that cmake automatically generates, the global file mmg_export.h in the folder “mmg\include\mmg” also expects a global mmgcmakedefines.h:

#include <mmgcmakedefines.h>

but there are only three such files in the subordinate folders mmg2d, mmg3d, and mmgs, not a global one. Maybe CMake should also manufacture such a global “mmgcmakedefines.h”.

However: If I can tell correctly, there is nothing so complex in the build process of mmg that absolutely requires CMake and can’t be done directly with a project file and Makefile. Personally I think it would be better to hand-write a Visual Studio project file for Windows, and a Makefile for Linux, and getting rid of CMake altogether but who am I to say …

#2

Hi Mathias,

Thank you for pointing out this omission. It should be fixed by the commit 469840ffddd4bfe7496f9fd2fceb2515d2c5e59d in the develop branch.

The initial choice to use CMake was made because of the relative simplicity of its use and its genericity and portability (I am probably unable to hand-write a Visual-studio project file…).

I recognize that the Mmg’s CMake could use some cleaning: we have an install process a little shaky due to the choice to allow to build separately each piece of code with common parts between codes but a non-modular architecture of the software. We also have some old stuff that the use of a recent cmake version should allow to delete… But honnestly I am afraid to broke something that works (at least in most of cases :wink: ).

For now, as I work in tense flow, I prefer to give priority to the correction of known bugs inside the remeshers. But thanks for sharing your opinion, it is always interesting to have a feedback.

Best Regards,
Algiane

#3

No worries, thanks for the fix, @Algiane !
For what it’s worth I wrote a solution and project file just for my own use, and it works pretty well … I could easily add some optimization options, an extra source file, and subjectively it compiles very quickly and generates a very fast mmg.dll (but I haven’t benchmarked it). It doesn’t have vtk, scotch, elas, fortran, etc but those can be added. In case anyone reading this is interested, it is here and it also has a build script here.

In my commits into that branch you see which problems I wanted to solve with it.
For example, I got the impression that the line

#include "mmg/mmg2d/libmmgtypes.h"

in libmmg2d.h, which includes a file that doesn’t exist in the source tree folder “src\mmg2d”, should probably be just

#include <libmmgtypes.h>

(meaning the file in the folder “src\common”) because that file is always the same, I think. But that’s just my speculation. Also, I was wondering if the symbol MMG_DYN_LIB should be defined as 0 if one wants to build a shared library. Maybe it’s less confusing/safer to define it as 1 because there is a line

#if(MMG_DYN_LIB)

in the file mmg_export.h which is not triggered if MMG_DYN_LIB is zero. But I might be wrong and am blaming cmake for something that’s actually my fault.

#4

Hi,

In my very remotes memory, I had a problem with the inclusion of <libmmgtypes.h> with multiple installation of different versions of Mmg in different directories… but honnestly I am not able to remember exaclty what happens…

Regarding the MMG_DYN_LIB variable, it should be defined as 1 for a shared library. Normally it is done at CMake’s configuration step:

CMakeLists.txt:89:SET(MMG_DYN_LIB ${BUILD_SHARED_LIBS} CACHE INTERNAL "" FORCE)

Best

#5

I see … however that raises a little confusion in the other case:
If the variable BUILD_SHARED_LIBS is off in cmake, cmake will preprocess the line

#cmakedefine01 MMG_DYN_LIB

from the file mmgcmakedefines.h.in into the line

#define MMG_DYN_LIB 0

in the generated file mmgcmakefines.h so that the symbol MMG_DYN_LIB is still defined in the C source code. It would still trigger the preprocess directive

#ifdef MMG_DYN_LIB
....
#endif

which is a little confusing. It’s not a problem because you use that preprocessor variable only in the line

#if(MMG_DYN_LIB)

in mmg_export.h which behaves correctly.

#6

Yes, I understand why you find this confusing: indeed, the MMG_DYN_LIB variable is always defined but it can be setted to 0 or 1 and we test its value to know if the dynamic libraries are built or not.
If you agree I will close this post as the initial issue is solved.

Best