Closed DavidR91 closed 7 years ago
Hmm...seems you're right. We prepared a formula a couple of weeks ago (https://github.com/cginternals/homebrew-cginternals) and got glbinding in the Homebrew code repository but somehow missed to integrate the one for globjects accordingly. We'll fix this as soon as possible. If you want to try our personal brew repository, you will notice it will install globjects 0.5 but this version is almost identical to the current 1.0 release.
Yep, that's fine for the time being - the 0.5 vs. 1.0 disparity is no problem, I just wanted to pull it down and try it out (without building from scratch)
For anyone else wanting to do that by the way:
brew tap cginternals/homebrew https://github.com/cginternals/homebrew-cginternals.git
before brew install
.
It seems that this package still isn't on Homebrew, any updates?
Sadly, no. All of our brew users (mostly macOS developers) are currently working on other tasks within our project landscape but I'm still trying to convince someone to adjust our glbinding package to globjects.
Gotcha. So the internal tap would still be the recommended way to use globjects on macOS then?
FWIW, I'd be willing to try to submit a PR to add globjects to homebrew based on the internal tap formula or adapting glbinding.
Currently yes, but I will definitely update this issue once it is available in Homebrew.
Any help would be appreciated :smile: : My main concern is that the formulas need testing before merging and I'm not confident enough to submit a formula where we just replaced the links and hash tags from glbinding, maybe add the dependency to glbinding, all without actual testing on multiple macOS version.
what do you mean by "links and hash tags from glbinding" exactly? From what I'm reading the formula test bot will handle testing the formula. I'm currently trying to model the test do
block after the one in glbinding, I should think that's sufficient? Maybe I should submit a PR to the internal tap before trying to submit one to the official Homebrew repo?
My main problem at the moment is that I'm not sure exactly what a minimal test to ensure globjects installed and behaves correctly would look like, as I'm currently unfamiliar with the library.
If I view the current version of the glbinding formula, the first lines contains the name, description, link to the archive and its sha256 hash. Updating these for globjects is obviously required. The following lines for the precompiled bottles are probably integrated by Homebrew maintainer as I assume a build infrastructure will provide the builds and only someone with access to the final builds may generate the required hashes. The dependencies needs to get extended by glbinding and I think there might be a small problem. To build globjects, cmake is required to find glbinding from the Homebrew dependency. In order to find glbinding, Homebrew has to install glbinding in a way that CMake finds this version or CMake needs knowledge about Homebrew how it organizes its bottles. I don't have any experience with Homebrew on this level. Ideally, the following workflow should work and a globjects formula similar to glbinding should be no problem:
Step 6 is crucial. glbinding is ideally intuitively found by CMake and I'm not sure if this is currently possible. If it is not found, we either have to adjust our deployment of glbinding in means of adjusting the glbinding formula or we have to adjust the find script of glbinding (would require a new release for Homebrew) or we have to tell the globjects formula how to help CMake in finding glbinding. The latter option would be the worst case as such manual adjustments would have to be done by anyone using glbinding or globjects as dependency.
Further I also think a test similar to the glbinding formula will suffice. You may submit a PR to our internal formula but I think actual feedback will come from the test bot or a Homebrew user/maintainer.
I just submitted a PR to the homebrew core tap that has been approved and passed their tests. Unsure when it will actually go live though.
Let's hope it gets integrated soon.
We really appreciate your help. With two and more working and accepted formulas in homebrew we're able to deduce templates in our cmake template project cmake-init (https://github.com/cginternals/cmake-init/issues/43).
This may be a dumb question but I'm a bit confused, you need homebrew formulas to deduce templates?
Yeah, I almost bet this would get a little bit confusing...I try to explain briefly what I intended to state earlier:
With cmake-init we try to create a cmake template for C++ projects covering most of a project setup for reoccuring development processes of a software project. One of them is deployment. As we apply the cmake template for all of our projects we set up, the required integration into third-party services should be quite similar. I assume: once we get enough projects to cover all combinations of relations between projects we have to create deployment scripts that are useful for all of our projects and that may be also useful for peers. Within this process, we strive for simplicity, portability and genericity.
With glbinding, we just have dependencies with third party libraries from Homebrew on an optional basis where globjects introduces an actual dependency to a project using the same project template as its dependency (glbinding with cmake-init). Therefore, I assume we can deduce a template on how to integrate arbitrary cmake-init-based dependencies into other cmake-init-based dependent projects.
Seems like it is merged (https://github.com/Homebrew/homebrew-core/blob/master/Formula/globjects.rb). I'll close this issue for now. Thanks for contributing.
Even after updating homebrew:
Error: No available formula with the name "globjects"
This link in the README is also a 404 ("This formula doesn't exists")
What is interesting is that GlBinding does exist - is globjects missing because the build machine is currently out of service?