Link many projects to single build of libigl

[alecjacobson]

I love the current cmake setup because it's very robust. My libigl based projects are almost always painless to install. Each of my projects either downloads libigl via cmake or uses libigl as a submodule. Then cmaking that subproject will also cmake (the correct version of) libigl.

The downside of this is that my sad little laptop is constantly heating up compiling libigl in static library mode. Each new project needs to compile the same libigl code, over and over again. I noticed that this has effected my workflow to the point that I might think twice about trying an idea because I know I need to wait 3 mins for libigl to compile or I opt for header only and pay the cost on every compile, or I have some messy mega-cmake with all my subprojects in it. Even after waiting for the big initial compile, the make traversal of all the igl-related compilation units is not entirely negligible: debugging is more painful when compiling takes many seconds.

Finally, there's an energy argument that regardless of cost/time we should be minimizing total energy consumption when we can. Recompiling the same code over and over again is clearly wasteful.

I'm not sure what the best solution is here. It's related to facilitating a system install of libigl. Maybe that should be the ultimate goal.

In the meantime, I created a modified FindLIBIGL.cmake that has a flag to link to a prebuilt copy of the libigl libraries and dependencies.

Is this something we want in the libigl-example-project? Is there a better way to go about this?

[jdumas]

Well to quickly try a new idea, it might be better to use libigl in header-only mode, so that you don't have to compile everything over again. Things like zapcc might also help.

To facilitate a system install of libigl, you can use a package manager that already has libigl packaged, e.g.:

• Conda
• Hunter
• Vcpkg
• AUR (for arch)
• gentoo package

I have thoughts on my own on how to facilitate a system-install of libigl, but this is part of a larger discussion on libigl's infrastructure that I'd like to have soon. The tricky part is that outside of the Eigen dependency, our other dependencies also need to be handled by said package manager to provide proper encapsulation.

Two things to note however:

• I would strongly advise against writing your own FindLIBIGL.cmake. This is the old way of doing CMake and it is bad for a number of reasons. The recommended way is to let CMake exports a LIBIGLConfig.cmake file and let your call to find_package(LIBIGL) find this file.
• Manually performing a system install of libigl is also bad for a number of reason. One should use a package manager such as conan, vcpkg, conda or hunter. So while we need to facilitate system install to create those packages, users should be encouraged to use a package manager rather than manually installing libigl on their system.

I would suggest to leave the libigl-example-project as is for now, until we have better support for package managers for all libigl modules.

[alecjacobson]

header only mode does not avoid compiling things. Rather it compiles just what's needed every time.

If I have n libigl-based projects, libigl has m total "compilation units", and a project uses k of such units, then we have:

Mode	First Compiles	Subsequent Compiles
Header only	O(n k)	O(n k)
Static library mode	O(n m)	O(n)
Pre-built mode	O(n + m)	O(n)

Even this is rather forgiving of the cmake clutter of using static library mode (O(n m) with a small constant factor to realize that everything is already built).

zapcc seems interesting, but I don't want to introduce yet another build system tool here. We ought to be able create a sustainable solution with cmake.

I'm not sure I understand about the notes. Someone is writing the FindLIBIGL.cmake. Didn't we write the one in libigl-example-project? Is it just a question of how much logic is in that file?

This isn't doing a manual system install, it's just reusing the build found someplace else. We compile a laundry list of libraries and dependencies (instead of one clean libigl.a), otherwise it seems pretty normal to provide a way to find headers and find a compiled library.

Returning to the time complexities above. Is a cmake solution to get O(n) performance?

[jdumas]

I'm not sure I understand about the notes. Someone is writing the FindLIBIGL.cmake. Didn't we write the one in libigl-example-project? Is it just a question of how much logic is in that file?

Yes, but it is not necessary (the only thing it does is call include() or add_subdirectory), and in fact we should remove it. CMake find_package() has two modes: a "module" mode and a "config mode":

• The "module" mode uses a FindFoo.cmake file, external to the project, to find an "installed" version of a library. It has to discover many package-specific configuration properties and "encode" all that logic. It is a legacy mode for package that are not installed by CMake or do not provide a CMake config file (e.g. a package installed by autotools).
• The second mode, "config" mode, is a more modern approach where an package installed on a given system comes with its own FooConfig.cmake file, that informs how targets were compiled and configured specifically. It can be (and should) be generated by CMake to handle tricky all use-cases (debug/release version, static/shared, version numbers, etc.)

See this talk for more information (watch at 2x speed). Bottom line: people shouldn't have to write a FindLIBIGL.cmake, and it's bad habit to encourage doing so.

This isn't doing a manual system install, it's just reusing the build found someplace else. We compile a laundry list of libraries and dependencies (instead of one clean libigl.a), otherwise it seems pretty normal to provide a way to find headers and find a compiled library.

Yes, but again that's why we really should be using a package manager. Even compiling something on your system in ~/workspace/libigl and then reusing it from another project is problematic. We all know how it ends up, you compile your project once, put it on github, and then 10 years later we don't know what version of libigl was used and the code doesn't compile anymore.

And the problem is not so much libigl itself as it is the gazillion third-party dependencies that we have outside of igl::core. Which is really why a C++ package manager is absolutely necessary.

Returning to the time complexities above. Is a cmake solution to get O(n) performance?

Yes, I believe hunter should help you. It is purely cmake-based, very easy to setup, and should download and compile libigl in a common shared folder for everyone to use.

Btw something else we could do to reduce compile time is well, make libigl faster to compile overall. There are many opportunities to do so, like stop being a header-only library (compile a few static files rather than force everything to be header-only compatible), reduce useless explicit template instantiation, use extern templates, use -ftime-trace to profile compilation bottleneck across libigl, etc.

Even with a system-wide install of libigl, if you're missing a specific template instantiation that you need in your project (e.g. you're using row-major matrices instead of column-major), you're gonna need to recompile stuff, whether you have a system-wide install or not.

[xarthurx]

As a user who happened to see this post, if libigl is recommending using package managers like vcpkg, would it be possible to reduce the release cycle?
For instance, the vcpkg is still installing the 2.2.0 version, which is release in April...
I tried 2-3 times, but always turned back to the source code version since I need sth newly changed or find some bugs and submitted accepted PR...

[alecjacobson]

would reducing the release cycle make this worse?

[xarthurx]

Sorry, I mean reduce the time of each release period -- increase the release frequency...

[jdumas]

The ideal solution would be a package manager that lets you install libigl from a SHA1 commit id. Even if we reduce release cycle (which I don't mind), there's always bound to be new bugfixes and features that are only available upstream.

[AndreyMlashkin]

Is it known, how much memory libigl consumes, while building as a static lib?
Currently, conan only 'builds' it in header-only mode and CI builds are failing for other modes (it works locally for me)
relates to conan-io/conan-center-index#7238