propositions

[ohenley]

Hi,

1) I was wondering if it would make sense to you to distribute the opengl lib as a submodule of OpenGLAda and therefore expose an Opengl-lib or something repo? At the moment we have to pull all dependencies (glfw, freeType) even if all we want is opengl.gpr.

I just finished a native Ada OpenGL Window lib (https://github.com/ohenley/aglw) that would eventually replace GLFW (win32 only for now). As-is AGLW is pulling all OpenGLAda as a third party submodule.

I "frankensteinized" some code found in common/ so that one of your demo can run using this AGLW lib. My main problem was dependencies on GLFW. You can find this demo here: https://github.com/ohenley/aglw-demos.

2) When we build opengl.gpr, it always complains that the obj and lib folder are missing. I know it is not critical at all but still annoying... IMO. To circumvent the fact that git does not create empty folders, I create a git.dummy file inside each lib, obj folder I want to distribute. Maybe you could do the same or maybe there is a better way to handle this small friction?

thx and ciao

[flyx]

Answering to 1.: I understand that currently, you need to download this complete repository to have access to the OpenGL binding, and this repository also includes those additional wrappers. However, you do not need to depend on any of the third-party libraries like GLFW and FreeType if you only import opengl.gpr in your project. Likewise, you can, after downloading OpenGLAda, execute gprinstall on opengl.gpr (with appropriate scenario variables) and then delete the repo clone. This way, you only install the core binding on your system.

I think it does no harm to keep the additional wrappers in this very repository, since their size does not justify keeping them in an own repository. Are the additional files really that much of an annoyance to you? Or maybe if I misunderstand your problem, perhaps you can explain it in more detail?

Answering to 2.: Just use the -p switch on GPRBuild; it will generate the directories. Sadly, there is no possibility to tell GPRBuild to automatically use this switch (at least when discussing this in #ada a while ago, nobody knew a solution).

[ohenley]

1. I already only reference opengl.gpr. AGLW-demos fetch your stuff as a git submodule, so ending up automatically with the bare minimum would be ideal (if opengl-lib was a repo in itself). Like said it is just a proposition. I do not mind downloading the whole thing.

The common folder has very valuable stuff but also sparse dependencies on those wrappers. I will continue to duplicate this code and strip/replace what I do not want to bring in.

2. Thx. Did not know about the -p switch

On Fri, Apr 13, 2018 at 4:38 PM, flyx notifications@github.com wrote:

Answering to 1.: I understand that currently, you need to download this complete repository to have access to the OpenGL binding, and this repository also includes those additional wrappers. However, you do not need to depend on any of the third-party libraries like GLFW and FreeType if you only import opengl.gpr in your project. Likewise, you can, after downloading OpenGLAda, execute gprinstall on opengl.gpr (with appropriate scenario variables) and then delete the repo clone. This way, you only install the core binding on your system.

I think it does no harm to keep the additional wrappers in this very repository, since their size does not justify keeping them in an own repository. Are the additional files really that much of an annoyance to you? Or maybe if I misunderstand your problem, perhaps you can explain it in more detail?

Answering to 2.: Just use the -p switch on GPRBuild; it will generate the directories. Sadly, there is no possibility to tell GPRBuild to automatically use this switch (at least when discussing this in #ada a while ago, nobody knew a solution).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/flyx/OpenGLAda/issues/125#issuecomment-381254472, or mute the thread https://github.com/notifications/unsubscribe-auth/ABXG1pEWKK2SQttkQ9lmCdRoqfGlGLNjks5toQyogaJpZM4TTuJt .

[flyx]

Untangling the basic lib from the additional wrappers will not happen. One of the reasons is that I cannot test anything without having at least the GLFW wrapper available (unless I pull AGLW as dependency, which would get both of us in the trouble of cyclic dependencies). I discussed other reasons above.

Semi-related: Most of the stuff in examples/common has been written by @rogermc2 . I do not have a complete overview of the functionality, but I think that some of those helpers could be nice to have in the main lib. If you encounter / clone functionality from there which you think may be part of the main project, feel free to open an issue / PR to include it.

I will close this issue as wontfix.

[ohenley]

Ok but, a submodule does not prevent this, right?

libAdaOpenGL (git repo): -opengl.gpr -generated/ -implementation/ -spec/ -etc

OpenGLAda (git repo): -Actual repo as-is with GLFW and stuff... except: a) src/gl is replaced by the submodule link: src/libAdaOpengl @ xyz_commit_id b) you --- with "src/libAdaOpenGL/opengl.gpr" --- in any other opengl-xyz.gpr c) proper cloning becomes: git clone --recursive https://github.com/flyx/OpenGLAda.git (append to README)

Sorry, I do not see what is the problem...

[flyx]

The problem is entropy. Having two repositories means having having two sets of branches, two places that may need a readme, two version histories, remembering to push to and update from the submodule, and so on. This places a heavy burden on me as the maintainer just to save you some KB of HDD memory. From my perspective, HDD memory is cheap while my time is not, so I fail to see any substantial return of investment.

The real problem is a very different one: Missing packaging. A package manager usually splits the library in several sub-packages, such as the binary (the usual package), the include headers (usually named -dev package), the documentation (usually named -doc) and possibly optional feature packages (which would be where the additional wrappers of OpenGLAda would go). If there was an OpenGLAda package, you could have exactly what you want.

Now since there is no package manager that packages OpenGLAda (at least none that I know of), you are including its source. But source code management follows different rules than package management, since its goal is to minimise the burden on the maintainers, not to maximise the comfort of the users. While I do use subrepos occasionally (git-subrepo imho is far nicer than submodules), I only span repositories I control. This is because there is no guarantee and no contract about layout continuity of other people's repositories. And this is why I suggested you use gprinstall to import OpenGLAda into your development environment instead of using a submodule.

[ohenley]

Let me disagree:

1) To be realist, entropy kicks in at a much bigger scale.

2) A proper separation of concerns would be to ship GLThickBinding in itself:

• Anyone could depend on it to whatever other project --> clean cut.
• Even in your actual context GLThickBinding do not have any dependencies what so ever. (except src/common utilities)
• Having split GLThickBinding before might have implicitly enforce not to bring GLFW and what not dependencies in src/common.

git submodules are great when properly used. Nevertheless thx for the git-subrepo pointer.

The submodule hash to your project I use is on a version that builds... on par with a version I would have gprinstall-ed. Same battle really.

I get it you do not want more maintenance job than you already have ... but IMHO to inflexibly defend the actual legitimacy of the "bundle" is counter productive.

Mosteo work "ALIRE: Ada LIbrary REpository" looks very interesting: https://github.com/alire-project/alr and a separate GLThickBinding would probably fit the bill.

[flyx]

A proper separation of concerns would be to ship GLThickBinding in itself

I think that's the point here: I don't ship. That's the task of package managers. I provide access to my repository, which is my development platform.

I started building an actual installer for Windows, which is located in the install directory and will be part of future releases. And that installer does have the option to not install any of the additional bindings (along with their libs). So you see, I do understand that a shipping package should be split. I just don't believe that a repository is something I ship.

I think we just have different ways of thinking about and using git. What I miss in your arguments is a description of the actual benefit you would get from split repositories. As said earlier, I believe saving some KB of HDD space is not a viable return of investment. I am trying to understand what other benefits are in there for you, but from what you're saying, I fail to see any. You're talking about a clean cut, but what actual benefit does that bring? Does it save work hours? I don't see how.

By the way, examples/common was never intended to be included elsewhere and might not be production-quality (I assume this is what you are talking about when saying src/common, since that does not exist). It's part of the examples, and they are just there to show how the binding can be used, not to provide additional utilities. So I think it's generally fine to copy from examples/common, but it is also fine to require you to adapt that code to your needs, like not depending on GLFW.

Concerning Ada packaging, another project that's currently being developed is Ravenports, which is not Ada-centric, but comes from the Ada community. I personally prefer Nix for platform-independent packaging, but alas, it has very poor support for Ada. Since none of the packaging projects aimed at Ada are currently adopted by a significant part of the community, I won't maintain OpenGLAda packages for the time being. But in the event of one becoming dominant, I will probably change that stance.