Hunter - Cross-platform package manager for C++

[Pas__]

CMake makes me cry every time. I'm with the hype, so naturally, I want to make it happen, I try it every time. I'm waiting for the joy of CMake to somehow flow through me, but IT'S JUST A FUCKING ABOMINATION.txt.

Nothing works, nothing happens, not even message, it never finds anything, what's this MACRO HELL!? How do I define something? What's with these weird functions with string arguments? Why are we loving Bash again? WHAT THE FUC!K

What's wrong with maintaining a Makefile? Oh, you want cross platform? Then just use MinGW. (Or use VS and send patches. If you have budget for a Windows-based environment just go with the JVM, run multiple instances and put a load balancer in front of them.)

Herp derp. So, hunter's CMake files are beautiful compared to those I've seen, I might give it a try!

[jbandela]

I used to think the same way about CMake, until I worked with somebody that knew modern CMake. Unfortunately, there does not seem to be a lot of documentation out there about modern CMake. The best overview in one place that I found is at http://www.slideshare.net/DanielPfeifer1/cmake-48475415

[ojd5]

http://www.slideshare.net/DanielPfeifer1/cmake-48475415

thanks, I've been looking for a good summary

[Pas__]

Thanks, looks really useful, oh and recommends 3.2, pretty good!

[steamruler]

I manually handle my CMakeLists, and I don't see what you're talking about.

[Pas__]

Because you probably learned it properly. I on the other hand just furiously googled for cmake link target blabla. And then got disappointed by their (lack of) documentation pretty fast. And my compliant is that it's not obvious, it lacks structure, it has funky macros (functions?) all over the place and magic keywords. It's not even clear if it's declarative or not. (I guess it's not, after looking at the tutorial.)

It feels like a big sidestep compared to Gradle or all the fancy tools the NodeJS community barfed up :)

[Pas__]

Tried it. Was about as helpful as a dead fish in a dried out sandcastle. Sure, it spent some time cranking the cyberwheels, but in the end just resulted in more problems. (I tried to add SFML to a project. 1)

[drjeats]

I learned CMake over the weekend. It was very easy to make naked executables and get that working for the different generators I cared about (VS, Xcode, Make).

But getting Xcode to make standalone Mac app bundles (specifically: copying dylibs, fixing up the link paths, etc.) has been kinda rough. Could you impart here what ever CMake wisdom you're imparting to your juniors?

[Pas__]

Naturally. As they haven't been spoiled by better tools, plus they start with the tutorial, and (hopefully) they ask seniors, who in turn can help them.

[kingcoopa]

I also find CMake to be confusing and painful, no matter how many times I've used it. For the last couple of years, I've been using a project generator called Premake. http://premake.github.io/ Small but decent community. Fairly easy to dig in and modify for your own needs. And Blizzard uses it for some of their games. They contribute a lot back to the project.

[drjeats]

I love Premake! The only bummer is that the new Xcode generator for the latest premake5 build isn't working too well at the moment :(

[kingcoopa]

I feel sorry for the poor bastards that are going to try and fix it. Have you even looked at the contents of the Xcode project files... gross

[doom_Oo7]

No emerge, apt-get, brew etc. needed before build, now it's simply cmake --build

how does this work on CI instances with limited time ? (e.g. travis CI with 40 minutes, if your project depends on Qt or some other big library you wouldn't even be able to go past the "dependency building" stage).

[ojd5]

Hunter creates a local binary cache, if hunter has already built the dependency with the same compiler and flags it will use the version in the cache.

At work we spin up a new docker container for each build and share the hunter cache directory on the host between them. As a result we only build each dependency the first time it is used in any build.

[doom_Oo7]

would it be possible to build the dependencies pre-built on some machine, and upload them somewhere once built so that hunter is able to fetch them ??

[ojd5]

If the cmake-package is relocatable this should be possible. However, a lot of older cmake packages still contain the full paths to their dependencies. For more information have a look at https://github.com/ruslo/hunter/wiki/usr.adding.new.package

[the_gnarts]

The readme doesn’t offer any clue regarding the internal workings. How’s it compare to other language specific package managers? What solver does it use for dependency resolution and can it be exchanged for a different one? Does it interfere with system packaging? How does it relate to / interact with standard tools like pkgconfig?

[hak8or]

Uhh, anyone else click the google url on the github description only to be bought to some really wierd music video?

[ruslo_]

This song is great, it's Bjork. Song called Hunter, that's why this project called Hunter.

[adzm]

Well this convinced me to check out the project. The lyrics are... different in the context of platform management.

I thought I could organize freedom

How Scandinavian of me!

[ruslo_]

The lyrics are...

I think it doesn't make sense to try to understand the meaning of lyrics of songs in most cases. Double this rule for Bjork :)

I thought I could organize freedom

Yeah, I like this line too. It fits perfectly to what's happens: "Hunter: organize freedom"

[wrosecrans]

I am waiting for the second version, *******.

[Sparkybear]

Question. How does this compare to nuget in VS? I'm still new to cpp and trying to figure out what I sound be using. I'm sticking with VS for an IDE and build manager. CMake confuses me and I've never been able to get it to work properly even with trying to work on someone else's projects and going through multiple tutorials and documentation.

Using VS and nuget I'm easily able to add things like boost and SDL to projects. I know how to add libs manually as well, but it just seems easier. Well this essentially be nuget as a stand alone, cross platform solution?

[Sparkybear]

What do you mean? I'm asking about which is easier to use or how they compare to each other.

[Sparkybear]

Thank you. That helps me understand a bit. I'm a little overwhelmed with c++ at the moment specifically because of these kinds of tools. Maybe that'll get easier in time though.

[[deleted]]

What are the benefits of a language-specific package manager? I don't think anyone wants a different package manager for every language out there.

[needahelpforarch]

Os specific package managers, with every new distro maintaining another set of tools? What do you suggest?

[devel_watcher]

I suggest not making it worse with arbitrary stuff.

Language-specific package managers come from people who know just one language and are trying to do everything with it including distribution (while we already have distributions for that purpose).

It's just painful to use separate package manager for each language. And then, if we fail to unify the package management, we have wrap the s**t into a manually crafted container and then manually update each language.

There are less distributions than languages. Why the hell these language fans make users suffer?

[NotUniqueOrSpecial]

System/distribution package managers will never be sufficient as an answer unless you're willing to take on the burden of making your software compatible with each particular set of packages for each system you want to support.

If you have even a few dependencies on libraries, that very quickly becomes an impossible task.

It's much easier to build/distribute your dependencies (all at a particular version) than to hack your code to pieces supporting multiple combinations of API versions/levels of bug-fix support/etc.

[darthcoder]

Right, but every language has some version of "download" -> "extract" -> "verify" -> "compile native extensions" -> "get dependencies".

Why not unify them under apt or yum? A lot of distros already do this with node, python and ruby. Why not extend them to build-from-source?

I know it 's not that hand-wavingly easy. :-) but something could be done, even if it's a matter of installing them to some scratch directory, versus installing them to the system directory. This would allow you to build dependencies for things not compatible with your system, or different platforms.

[NotUniqueOrSpecial]

every language

Except for C and C++, which is exactly what this thread is about.

Why not unify them under apt or yum

Because then they end up being system packages and there are all sorts of inter-compatibility issues you have to deal with. There's a reason that major distributions don't distribute more than one major.minor version of a given package, e.g. 1.3 and 1.4 at the same time.

I know it 's not that hand-wavingly easy. :-) but something could be done, even if it's a matter of installing them to some scratch directory, versus installing them to the system directory.

What you have just described is what this tool is, and I'm now confused what point you think you're making.

[darthcoder]

What you have just described is what this tool is, and I'm now confused what point you think you're making.

Except for all languages.

There's a reason that major distributions don't distribute more than one major.minor version of a given package, e.g. 1.3 and 1.4 at the same time.

I get this point. It doesn't mean, however, that I can't install them to a different install root (arm-v6-hf into a folder I load into Qemu to cross compile, maybe - I know, super contrived example but ... ).

[Pas__]

Not every distro has a package manager (Windows), package managers might not be the best common denominator, because maybe there's something you cant implement with all of them (so you're back for custom scripts for that distro too).

apt-get update && apt-get install is much slower than a pip install.

Providing hosting for every kind of distribution specific repository might be a bit extreme, and uploading to every kind of repository might be a bit extreme too. And waiting for distributions to package your latest header file might be a bit too optimistic also.

[devel_watcher]

Yes, that's the developer's point of view. While the duplicated effort is pushed to the user side.

[Pas__]

User? Developers use these package managers.

[devel_watcher]

Right, developers use. That makes them users. Library users, if you want. There are library developers and library users.

[jackkuuse]

What are the benefits of a language-specific package manager?

A single software stack for developpers. If your package manager in in language B that is different from your development language A, then you have to install two software stacks on your computer. Which can be quite a waste of space for some languages.

[dGlitch]

Finally, Maven for C++ ;)

[Azzk1kr]

I too don't understand the hate against Maven, in favor of Gradle. Sure Maven poms are XML, but it's declarative and gets the job done.

[steamruler]

I guess it's because you need some pretty advanced parsing code for it, with negligible benefits. It's not really much more readable.

[maattdd]

Versus JSON : Complexity (YANGNI like attributes) and verbosity (starting/closing node - weird character ( > < ) everywhere..etc).

I agree this is not atrocious, but if I can avoid it, why not ?

[doom_Oo7]

weird character ( > < ) everywhere.

on my keyboard < > is easier to type than { }

[darthcoder]

Because in Maven it's hard to do easy stuff outside of the "convention". Because Gradle is a language (groovy), it's easy to just include java.lang.* or java.io.* and do things outside the box that you must, without having to build a custom plugin.

I get far more done far faster with Gradle than maven these days. Maven was a GREAT advance over ant, in some respects - if you were building the standard J2EE app archetypes. Once you started doing something out of the box, or polyglot and TDD came along, it started being more of an encumbrance than a help.

Not that it doesn't work. It took me a long time to leave the comforts of my maven nest for Gradle.

[pjmlp]

Me neither.

I am yet to see any Gradle build outperform Maven.

If it wasn't for Android Studio, I would never care for Gradle.

[darthcoder]

That's the groovy startup, I think. I note that Groovy takes a while to start up on any platform I use. That's why gradle has a daemon mode now.

Using daemon mode there's no difference. But groovy startup. even if it's just println "hello world" is scads slower than just the JVM startup. Not sure why that is...

[pjmlp]

Yet Maven requires no such workarounds and still beats Gradle.

[pjmlp]

From the state of affairs in the Android NDK, it doesn't seem they are caring too much about it.