[madhadron]

> build tooling...is miserably underengineered for modern, dependency-heavy environments.

My advice about build tooling is to use buck (from Facebook) or bazel (from Google). If you have an ex-Googler nearby, use Bazel. If you have an ex-Facebooker nearby, use buck. Otherwise flip a coin.

[paulddraper]

While I love these projects, neither one of these actually fix the problem of an ecosystem of dependencies.

Buck and Bazel were created for complex internal dependencies.

You'll have just as easy/hard of a time getting Boost installed with Bazel as you would for Make.

Or publishing an accessible library that depends on Boost.

[SolarNet]

> You'll have just as easy/hard of a time getting Boost installed with Bazel as you would for Make.

> Or publishing an accessible library that depends on Boost.

This is patently false. Here is the bazel dependency for boost (put this in your workspace file):

    git_repository(
        name = "com_github_nelhage_rules_boost",
        commit = "6d6fd834281cb8f8e758dd9ad76df86304bf1869",
        shallow_since = "1543903644 -0800",
        remote = "https://github.com/nelhage/rules_boost",
    )

    load("@com_github_nelhage_rules_boost//:boost/boost.bzl", "boost_deps")
    boost_deps()

No other installation necessary. If someone has a C++ compiler and Bazel installed that will allow you to build against Boost deps (e.g. "@boost//:callable_traits"). No downloading boost by hand, no building boost by hand, no managing it's build, bazel does all of that.

Bazel does have a dependency ecosystem, it's based off of hashed versions of publicly available git repos and http archives (and anything else you want really). Which means any code anywhere can be a dependency while still being reproducible. Additionally you can provide local build instructions for the external code, so you don't even need to rely on their build. The better way is to find someone who maintains a BUILD file for a repo (or mirror and maintain it yourself) but still.

[paulddraper]

Boost may have been a bad example, since it is a common dependency, without any sub-dependencies.

To beetwenty's point, the C++ ecosystem in general lacks the the level of support for dependency ecosystems that you find in Maven, pip, gem, npm, etc.

Bazel external dependencies are in fact a real pain point. See the 3+ year old Bazel Recursive WORKSPACE proposal. [1]

I was at the first Bazel Conf in 2017, and the external dependencies meeting was quite the row.

[1] https://bazel.build/designs/2016/09/19/recursive-ws-parsing....

[SolarNet]

I feel like that's a misunderstanding of the issue. Recursive dependencies are orthogonal to the issue of having an ecosystem of dependencies. There is a pattern for recursive dependency management (did you notice the `boost_deps` recursive dependency call?) that is currently fine for production that recursive workspaces will make better.

Also as demonstrated Boost is way easier to include in bazel than make which was the original issue under discussion.

I make a library that depends on boost, here is how you use it:

    git_repository(
        name="foo"
        ...
    )

    load("@foo//:foo/foo.bzl", "foo_deps")
    foo_deps()

magic

[veselin]

The trick is that now one will depend on somebody who is not boost for these nice mappings. I brought such a dependency for gRPC once and now it doesn't work with bazel 1.0. I either have to find the author, understand all the bazel trickery, or switch to something else, because most of these bindings depend on many bazel features.

So, bringing such multiple third party bandaid is currently not such a great idea. It would be a bit better if boost itself provided it.

[SolarNet]

Wasnt this because the dependency for gRPC was moved into bazel itself?

How is this different than most other build systems? You always have to rely on others.

[mehrdadn]

What kinds of problems do you run into with Boost on Bazel? Are there no available build files you can just drop and use directly?

[madhadron]

Ah. Yes, I wasn't the one who had to get Boost into Buck, so I don't know the pain. But I also have been told to avoid Boost for modern C++, so...

[gumby]

I need boost, but mainly because I use other packages than depend on boost.

I also use boost when the compiler is behind (e.g. boost::variant until apple's compiler caught up).

I can't wait to have a boost-free tree. but I suspect it will be a while.

[hackandtrip]

Why would someone avoid Boost?

[Piezoid]

I have seen a library with a copy of boost in the include folder. Client code is forced to use this outdated version and must avoid transitive dependencies to boost. Please don't do that.

[louiz]

It’s a very heavy dependency, in many ways.