Use GLAD2 in-tree #107
Use GLAD2 in-tree #107
Conversation
|
Hi @rapgenic, Thanks for looking into this. I'm trying to understand if this is the best decision. IMHO in-tree dependencies are a shortcut that lead to more issues down the road (especially submodules and
That's unfortunate, however Conda-Forge is a community effort. We (and other interested people) can step up to maintain the feedstock.
I definitely know very little about Glad, but it seems orthogonal from the way we resolve that dependency. Do you mean that is only needed at compile time but not runtime? If it is, that's a case supported by conda recipes. |
|
Hi @AntoinePrv, I totally agree with you on not liking in tree deps, however I feel this is a little different corner case. As I said before, GLAD is not really a library that you should load at runtime (e.g. shared library) neither a source library that you need to include at compile time. Rather it is a bunch of generated glue code that allows to load OpenGL functions. As such it should be specifically generated for each project, depending on the needed features (e.g. desired OpenGL version compatibility). So having a pre-made recipe makes little sense (which is why the feedstock maintainer also abandoned the previous package). An alternative to including the submodule (which is what I did first when I started using it, and actually what is recommended by GLAD itself) would be generating the glue code on their website and simply including the sources in our repo. I went for the other option to have to track less code, but it really doesn't matter, we could do that if it's cleaner to you, that code will never change anyway. Lastly, the feedstock maintainer has recently published a new version containing only the generator and not the generated code, but it seemed to me that it was missing the cmake integration, which I didn't want to rewrite. In the end, I'm not sure it is worth it to maintain and use a whole other conda package to tackle such a simple and specific problem. |
There was a problem hiding this comment.
Thanks for the explanation. I understand better why the current package is not well-suited.
My main worry is that at some point in the future, we will need to make some change (e.g. WASM) or someone is gonna have a problem with the sub-module, will want to get rid of the vendoring, and they would have to figure things out again.
I'd like to find a way to be explicit about "this code is generated a compile time, it is not a static library".
Lastly, the feedstock maintainer has recently published a new version containing only the generator and not the generated code, but it seemed to me that it was missing the cmake integration, which I didn't want to rewrite.
Which one is it? I could take a look. I think that would be the most explicit option.
An alternative to including the submodule (which is what I did first when I started using it, and actually what is recommended by GLAD itself) would be generating the glue code on their website and simply including the sources in our repo.
Alternatively I think this is preferable to sub-module.
In the end, I'm not sure it is worth it to maintain and use a whole other conda package to tackle such a simple and specific problem.
From a single project perspective, it can be faster yes. From a community point of view, there is value in having a package that does the proper thing.
| find_package(glfw3) | ||
|
|
||
| find_package(PkgConfig REQUIRED) | ||
| pkg_check_modules(octinterp REQUIRED IMPORTED_TARGET GLOBAL octinterp) | ||
|
|
||
| add_subdirectory(glad/cmake) | ||
| glad_add_library(glad-static STATIC API gl:compatibility=1.1) |
There was a problem hiding this comment.
So if I understand, this is where the custom/glue code is generated?
|
I'm so sorry, I missed the notification.
Thank you! It's called glad2. |
|
Let's see how we plan this in conda-forge/glad-feedstock#7 |
Talking to glad conda feedstock maintainer, I have found that he's not maintaining it anymore.
Plus, glad should not be used as a general purpose library but rather as a generator for opengl headers according to the needed OpenGL specification.
I've replaced the conda package with a submodule, which integrates nicely with cmake, and added the generation of OpenGL headers with compatibility for OpenGL 1.1 which seems to be what octave needs.