Why export only igl::{core, common} targets

[Janos95]

Hey igl devs, If I'm understanding correctly the current cmake script only exports the igl::{core, common} targets. What is the reason for doing so? When installing the library and then trying to find the cmake config file, it is therefore at the moment not possible to link against say the igl::opengl target.

[jdumas]

The reason is that other modules depend on other libraries, which makes exporting them properly with CMake more difficult, so it's not implemented yet. The recommended way to use libigl in your project is to build from source, as in the libigl-example-project. Anything beyond that is still experimental and/or incomplete, and only provided as a convenience for advanced users.

[Janos95]

So I am looking into exporting the opengl, opengl_glfw and opengl_glfw_imgui components. Opengl is found through cmake the other two and the dependency glad are downloaded using a cmake script (BTW may I ask why there are these complicated downloading scripts, as far as I can see everything is hosted on github, so I think it would be much easier to use git submodules instead). All three (glad, glfw and imgui) do not export themselves. So one has to change that and then it should be rather straight forward to export the igl components I think.

[jdumas]

git submodules are horrible to use. We had that before, but downloading external content through cmake is much easier for the user (in CMake 3.11 it's called FetchContent). Our philosophy is to download everything and compile all necessary dependencies within the same project. The reason is that, contrary to a system library where you have all your .so and the package manager is ensuring your keep using compatible versions, research code is typically written once, and after the project gets published it's never really touched anymore. So if you have code from 10 years ago and you want to recompile and run it, it's much easier if the correct version of each dependency is downloaded and compiled as part of the project build, versus having to downgrade system libs and what not because the API has changed in 10 years.

But we can talk about improving the build system if it doesn't satisfy your needs. E.g. a good principle to follow, is that if the user already has a target glad::glad in his CMake script before including libigl, then libigl will use this target and will not download glad (I'm using glad as an example but it's the same for all third-party libraries). Then the responsibility is on the user to make sure they use compatible libraries. The user can set up git submodules or whatever they want to get said library.

[aWilson41]

I second this, these targets should be imported. Externally, anything outside of core and common are impossible to use in projects that use LibIGL without finding them yourself. You shouldn't need to export the targets of your dependencies. You just need to import tetgen as a interface target in both your cmake and the config (using find_dependency).

[jdumas]

Btw if that's any consolation, the recommendation for production use is to compile everything at the same time with the same flags. That means build everything from source with the same CMake, and don't "import/export" your libraries.

[essex-edwards]

I also wish that the "install" step would include more of igl's targets. I'd like to treat libIGL like all of my other third party dependencies: distributed to CI and other devs as pre-built binaries.