search

jupyter-xeus / xeus-octave

Jupyter kernel for GNU Octave
https://xeus-octave.readthedocs.io/
GNU General Public License v3.0
57 stars 10 forks source link

Use GLAD2 in-tree #107

Open rapgenic opened 1 year ago

rapgenic commented 1 year ago

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.

AntoinePrv commented 1 year ago

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 add_subdirectory). Did you encounter issues with the current situation?

Talking to glad conda feedstock maintainer, I have found that he's not maintaining it anymore.

That's unfortunate, however Conda-Forge is a community effort. We (and other interested people) can step up to maintain the feedstock.

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 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.

rapgenic commented 1 year ago

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.

rapgenic commented 1 year ago

I'm so sorry, I missed the notification.

Which one is it? I could take a look. I think that would be the most explicit option.

Thank you! It's called glad2.

AntoinePrv commented 1 year ago

Let's see how we plan this in https://github.com/conda-forge/glad-feedstock/issues/7