EditableProject Template for External Plugins

[mariuszhermansdorfer]

Hi @Grantim & @Fedr!

MeshLib comes with an EditableProject template for MeshInspector plugins. Could you please provide a similar template for plugins which leverage MeshLib in other applications?

Here is why I need this: I have a bunch of c++ code building on top of MRMesh and MRCuda. The high level functions are then exposed via C interface to managed c# code (extern "C" __declspec(dllexport)). So far, I've been keeping everything in two source files, one in MRMesh, another one in MRCuda:

Each time I pull the newest source from GitHub, I need to manually reintroduce these files which makes it annoying in the long term.

The other reason is that I ran into conflicts with external dependencies of MeshLib clashing with same dependency but different version in the receiving application (Rhino). I'm working with Rhino developers on this one and we suspect OpenVDB is causing the issue. I don't use it anywhere in my code, but I believe MeshLib refuses to run if it's not included.
To avoid similar issues in the future, I'd like to reduce the amount of dependencies my project uses. Currently, I'm including the whole long list of DLLs generated when MeshLib is built.

Do you have good suggestions on how to structure my project to address both points?

For reference, these are the includes I need in my code:

#include "MRMesh.h"
#include "MRMeshBoolean.h"
#include "MRMeshIntersect.h"
#include "MRLine.h"
#include "MRContoursCut.h"
#include "MRPolylineProject.h"
#include "MRPolyline.h"
#include "MRParallelFor.h"
#include "MRMeshDecimate.h"
#include "MRDistanceMap.h"
#include "MRRegularGridMesh.h"
#include "MRFillContour.h"
#include "MREdgePaths.h"
#include "MRMeshSave.h"
#include "MRExtractIsolines.h"
#include "MRDistanceMapLoad.h"
#include "MRPointsLoad.h"
#include "MRPointCloud.h"
#include "MRTerrainTriangulation.h"
#include "MRAggregateFlow.h"
#include "MRBitSetParallelFor.h"
#include "MRRingIterator.h"
#include "MRPointsInBall.h"
#include "MRAABBTreePoints.h"
#include "MRRegionBoundary.h"
#include "MRMeshFillHole.h"
#include "MRMeshSubdivide.h"
#include "MRPositionVertsSmoothly.h"
#include "MRPolylineDecimate.h"
#include "MREmbedTerrainStructure.h"
#include "MRFillContours2D.h"
#include "MRPointsProject.h"
#include "MROffsetContours.h"
#include "MR2to3.h"
#include "MRPolyline2Intersect.h"

and in Cuda:

#include "MRMesh.h"
#include "MRCuda/MRCudaSolarRadiation.h"
#include "MRCuda/MRCudaBasic.h"
#include "MRMeshIntersect.h"

[Grantim]

Hello!

I suggest in your case the easiest way is to have MeshLib as submodule of your solution like this

MeshLib/readme.md

Lines 257 to 261 in b6c0f54

	### Submodule
	You can have MeshLib as submodule in your repository, and inculde all MeshLib's projects to your solution.
	> **_NOTE:_** You should use `MeshLib/source/common.props` in other projects of your solution.
	> **_NOTE:_** You can customize props by defining `CustomMRProps.props` in directory above `common.props`

and with CustomMRProps.props you can define any of these macro

option(MRMESH_NO_CLIPBOARD "Disable clipboard support for Linux and Mac" OFF)
option(MRMESH_NO_PDF "Disable PDF support" OFF)
option(MRMESH_NO_CPR "Disable CPR tests" OFF)
option(MRMESH_NO_PYTHON "Disable Python bindings" OFF)
option(MRMESH_NO_DICOM "Disable DICOM image support" OFF)
option(MRMESH_NO_LABEL "Disable support of label objects" OFF)
option(MRMESH_NO_JPEG "Disable JPEG support" OFF)
option(MRMESH_NO_PNG "Disable PNG support" OFF)
option(MRMESH_NO_TIFF "Disable TIFF support" OFF)
option(MRMESH_NO_VOXEL "Disable voxel support" OFF) # openvdb
option(MRMESH_NO_GLTF "Disable glTF support" OFF)
option(MRMESH_NO_XML "Disable XML support (affects 3MF support)" OFF)
option(MRMESH_NO_E57 "Disable E57 support" OFF)
option(MRMESH_NO_OPENCASCADE "Disable OpenCASCADE usage" OFF)
option(MRMESH_NO_ZLIB "Disable Zlib usage" OFF)

So you will be able to reduce number of dependencies (we didn't really test it on windows, but I believe it should work)

---

So your solution should look like this

CustomMRProps.props file:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <_ProjectFileVersion>10.0.40219.1</_ProjectFileVersion>
    <_PropertySheetDisplayName>Common properties customizatoin</_PropertySheetDisplayName>
  </PropertyGroup>
  <ItemDefinitionGroup>
    <ClCompile>
      <PreprocessorDefinitions>MRMESH_NO_PNG;MRMESH_NO_JPEG;MRMESH_NO_DICOM;MRMESH_NO_PDF;MRMESH_NO_XML;MRMESH_NO_GLTF;MRMESH_NO_ZLIB;MRMESH_NO_CLIPBOARD;MRMESH_NO_E57;MRMESH_NO_CPR;MRMESH_NO_VOXEL;MRMESH_NO_OPENCASCADE;_ITERATOR_DEBUG_LEVEL=0;%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ClCompile>
  </ItemDefinitionGroup>
</Project>

MeshLibWrapper.vcxproj file:

     </ImportGroup>
+++  <Import Project="$(ProjectDir)\..\..\MeshLib\source\common.props" />
     <PropertyGroup Label="UserMacros" />

SubmoduleSolution.zip

[mariuszhermansdorfer]

Looks super good! Will test and report back. Thanks @Grantim!

[mariuszhermansdorfer]

Thanks @Grantim, this looks very promising. I took your example and build it with the following settings:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <_ProjectFileVersion>10.0.40219.1</_ProjectFileVersion>
    <_PropertySheetDisplayName>Common properties customizatoin</_PropertySheetDisplayName>
  </PropertyGroup>
  <ItemDefinitionGroup>
    <ClCompile>
      <PreprocessorDefinitions>
	  MRMESH_NO_CLIPBOARD;
	  MRMESH_NO_PDF;
	  MRMESH_NO_CPR;
	  MRMESH_NO_PYTHON;
	  MRMESH_NO_DICOM;
	  MRMESH_NO_LABEL;
	  MRMESH_NO_JPEG;
	  MRMESH_NO_PNG;
	  MRMESH_NO_TIFF;
	  MRMESH_NO_VOXEL;
	  MRMESH_NO_GLTF;
	  MRMESH_NO_XML;
	  MRMESH_NO_E57;
	  MRMESH_NO_OPENCASCADE;
	  MRMESH_NO_ZLIB;
	  _ITERATOR_DEBUG_LEVEL=0;%(PreprocessorDefinitions)
	  </PreprocessorDefinitions>
    </ClCompile>
  </ItemDefinitionGroup>
</Project>

But still see Python in the output even though it's explicitly excluded above:

[Grantim]

But still see Python in the output even though it's explicitly excluded above:

Python is copied as post build script for MRMesh, its hard to skip this now, anyway I think it is not linked to main dll, so you can remove them from final distribution

---

EDIT: Probably it is linked, unfortunately to get rid of python in this case it will require some changes in MeshLib (zip file is not used)

[mariuszhermansdorfer]

Thanks @Grantim. This is not a pressing matter. Having followed your steps, I was able to remove the dependency on OpenVDB and now my plugin again works well with Rhino.

Thanks for a super fast response as usual!

As far as I am concerned, this issue can be closed now.