Add libigl

[AndreyMlashkin]

Specify library name and version: libigl/2.3.0

closes #3335

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[AndreyMlashkin]

"ERROR: libigl/2.3.0: Error in build() method, line 86
self.copy("LICENSE.*", dst="licenses", src=self._source_subfolder)
AttributeError: 'LibiglConan' object has no attribute 'copy'"

What's wrong with this line? I have seen many similar in the other recipes, for example:
rocksdb/all/conanfile.py: self.copy("LICENSE*", dst="licenses", src=self._source_subfolder)

[SSE4]

"ERROR: libigl/2.3.0: Error in build() method, line 86
self.copy("LICENSE.*", dst="licenses", src=self._source_subfolder)
AttributeError: 'LibiglConan' object has no attribute 'copy'"

What's wrong with this line? I have seen many similar in the other recipes, for example:
rocksdb/all/conanfile.py: self.copy("LICENSE*", dst="licenses", src=self._source_subfolder)

AFAIK self.copy only allowed in certain methods, e.g. it works in package but not in build

[AndreyMlashkin]

Need a bit help here. Build process does not produce a lib if shared=True

@dvd0101 @scottsha

[uilianries]

Thank you for your contribution, please, take a look on my review.

[AndreyMlashkin]

I need some help here
@dvd0101 @scottsha @uilianries @SSE4

[SSE4]

seems like upstream doesn't provide an install target, so... files have to be copied manually.

[uilianries]

Weird, I can see install method for CMake: https://github.com/libigl/libigl/blob/v2.3.0/cmake/libigl.cmake#L533

[AndreyMlashkin]

It seems, the library behavies as a header-only if shared=true. It does not produce a lib, but it can be used.

What's the best way to avoid conan hooks?
I can for example, make the lib to be static only and remove shared flag

[AndreyMlashkin]

I have submitted an issue about x86 and arm builds upstream:
libigl/libigl#1888

[AndreyMlashkin]

@jgsogo , what's wrong with the CI?
Is it the same error, as on Windows? There is not enough RAM and we have disabled Win build

[jgsogo]

I think the problem is with RAM memory on Linux PODs. Did anyone try it locally with different memory limits? I think we have 6Gb available now.

[AndreyMlashkin]

I have started docker with
docker run -it --rm --memory="6g" conanio/gcc10
and it went through.
I am using windows, but it should not matter in this case

[jgsogo]

This is the output I can get: https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/5542/72-production/libigl/2.3.0//summary.json

In that last run, only the Linux jobs were pending (UNKNOWN), this is why I think it is something related to Linux... I don't have the numbers about how long it was running for Linux, but it was hours so probably something was going wrong with it. All of them are DEBUG builds, so probably it is just those builds that require much more memory.

[AndreyMlashkin]

So, there are no any build logs or something?

[jgsogo]

So, there are no any build logs or something?

When a POD crashes, we are not able to get the log (we could use other strategies, ping @davidsanfal ). The log is written to a file and then uploaded. If the process is killed it will be lost together with the POD.

[AndreyMlashkin]

You could write a file to some shared volume :)

[conan-center-bot]

All green in build 73 (6675244a0f16e20061e33b38df8cf0c3c9ffeafa):

• libigl/2.3.0@:
  All packages built successfully! (All logs)

[AndreyMlashkin]

I have left only header-only option.
Once it is merged, I will create another PR, removing the check

[AndreyMlashkin]

@SSE4 @uilianries @jgsogo, please approve