mosra/magnum

Feature Request: Install a `pkg-config` file.

andre-caldas opened this issue ยท 5 comments

It would be nice to have a magnum.pc file installed in the proper place.

I do not use cMake. Currently, I am using the build2 toolchain. Having a magnum.pc file would allow build2 to easily use an installed Magnum library.

I actually intend to "package" the Magnum library for the project build2-packaging. This way, the toolchain would be able to automatically download and install the library for other build2 users.

Sorry but I'm afraid I can't do that. I'm struggling to publish regular releases even, I definitely don't have the bandwidth to maintain support for another buildsystem in addition to CMake.

If Magnum would be a self-contained project, sure, but -- especially with the plugins -- there's 40+ optional dependencies and I have enough pain dealing with just even the 3rd party CMake files, which I often have to either patch or recreate from scratch. I can't even begin to imagine what would it involve to extract the linker and include path information from the dependencies to put them into a *.pc file. Especially with static builds this gets out of hand quite fast, and Magnum itself has several optional components the config file generation would need to take into account.

That being said, if you're willing to maintain that on your own, I'm happy to answer questions, and mention the pkg-config support in documentation in case you decide to make it public. People have successfully used Magnum with bazel, waf or even plain Makefiles, but in all cases those are downstream projects maintained by someone else. Here's documentation of the library dependency order which should hopefully be enough to get you started. I can expand that further if needed.

Sorry but I'm afraid I can't do that. I'm struggling to publish regular releases even, I definitely don't have the bandwidth to maintain support for another buildsystem in addition to CMake.

That is okay! :-)
For the time being, I can generate a .pc just for my case.

That being said, if you're willing to maintain that on your own, I'm happy to answer questions, and mention the pkg-config support in documentation in case you decide to make it public. People have successfully used Magnum with bazel, waf or even plain Makefiles, but in all cases those are downstream projects maintained by someone else. Here's documentation of the library dependency order which should hopefully be enough to get you started. I can expand that further if needed.

I am quite new to build2 (8 days!). And also new to Magnum (I have successfully compiled and installed ๐Ÿฅ‡).

When the time comes, I will try develop and maintain it. I hope it will not be very complicated because Magnum is so well organized and documented... and I know you try very hard to keep up with your very successful design decisions. I have read your post A Decade of Magnum. ๐Ÿ’ฏ

I just hope those other libraries you depend on do have .pc files...

By the way, funny story...
I was using Ogre3D, and I was asking an AI about a graphics library that treats Points and Vectors as different entities. And the AI pointed me to Magnum as if it was such a thing. I got really happy I had discovered this amazing project of yours! (that is not a geometry library and also does not treat points and vectors as different stuff ๐Ÿ˜…)

Thank you for the great work!!!

I was asking an AI about a graphics library that treats Points and Vectors as different entities

Well the AI is not wrong, they were there, in 2012: 071afa0 ๐Ÿ˜„ Though it turned out to be a massive PITA so I removed them again not even a year later (89c76e2 contains the reasoning, 58d156b removes them). In retrospect, it was a good thing that I tried to have those types, because otherwise I wouldn't be able to realize that they don't add enough value to be worth having.

Oh and it's not wrong about a "geometry library" either -- the whole Magnum::Math namespace is available as a single-header library if you'd need really just that: https://github.com/mosra/magnum-singles (and there you don't need pkg-config at all, haha). There are projects that happily use just those single-header libraries together with custom renderers. The math library has hooks for integrating with 3rd party types so it could be made to work nice with Ogre's types, for example, even the single-header variant. There's already such integration for GLM and Eigen.

I was asking an AI about a graphics library that treats Points and Vectors as different entities

Well the AI is not wrong, they were there, [...] I removed them again not even a year later (89c76e2 contains the reasoning, 58d156b removes them).

I see. :-)
It seems you had problems with homogeneous coordinates, because it adds some redundant information that gets easily corrupted (for sure... like $1 + 1 = 2$). Pun intended!

In my case, I want them both to have exactly the same representation in memory. But I want different types: $p + v = p$, $\alpha v = v$, $v + v = v$, $p - p = v$. But in principle, although things like convex combinations of points make sense... I do not want to unintentionally be doing: $p + p$ or $\alpha p$. And of course... a vector and a point transform differently and, in particular, they give different homogeneous coordinates, because vectors are not "displaced".

PS: Even before posting here, I posted in the build2 chat that I intend to package Magnum. And I have just checked a guy, there (fred) told me he was the guy who ported Magnum to Conan... in his old times... before build2. So... it seems I have a good consultant. :-)

https://github.com/helmesjo/conan-magnum and, yeah, there was a lot of suffering involved because Conan has very strong opinions about certain things such as dynamically-loaded plugins ๐Ÿ˜… That was also a reason why the effort ultimately failed, maintaining that package was just too much wheel reinvention.

So if I can suggest, try to make just your particular use case work, let's say a dynamic build with the libraries / plugins you need, and remaining options left at default. That's what I do for ArchLinux, Debian, Fedora, Homebrew... packages as well. Don't try to expose all the options because there's a lot of them and ensuring all combinations work well is a massive amount of work.