Possible to use boost git repos + commit hash instead of tarball?

[MarkusTeufelberger]

Right now you seem to pull from your own mirror, which is not sustainable and a bit hard to keep up-to-date.

With git repos there might also be a chance to expose more than a single version of boost, by pinning various different commit hashes to different library versions.

[MarkusTeufelberger]

Ah, maybe I didn't express myself clearly:

Instead of using

rules_boost/boost/boost.bzl

Lines 125 to 134 in 0be1390

	http_archive(
	name = "boost",
	urls = [
	"https://%s.dl.sourceforge.net/project/boost/boost/1.67.0/boost_1_67_0.tar.gz" % m
	for m in SOURCEFORGE_MIRRORS
	],
	build_file = "@com_github_nelhage_rules_boost//:BUILD.boost",
	strip_prefix = "boost_1_67_0",
	sha256 = "8aa4e330c870ef50a896634c931adf468b21f8a69b77007e45c444151229f665",
	)

I'd like you to use https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/repo/git.bzl rules instead, so it is easier to choose the version of boost to build against. In the beginning you hosted your own tarball of boost, they nowadays seem at least to also ship it in an official location too, so it has already gotten better.

It might still be nice to say that a project uses "Boost::foo at commit 1234abcd and Boost::bar at commit 5678ef90" instead of having the full boost tarball loaded all the time, but that's maybe not as important nowadays.

[nelhage]

Whoops, my bad! That closes: line was a typo :(

[reltuk]

Is this still something people are interested in?

Modularized boost has a nice layout and actually results in simpler rules, but the submodule init seems way too slow...

[Kernald]

Is mixing different versions of Boost modules even desirable? I don't think downloading time is an issue as you're unlikely to do that often, but I don't really see any value in not downloading the whole tarball for that exact same reason.

[reltuk]

Yeah, picking and choosing different versions of different boost libraries doesn't seem all that desirable. If we had the modularized build, it would be easy to create your own git repo with the submodules pointing to different places if you really wanted to.

So this feature request is to basically just support the structure found at https://github.com/boostorg/boost?

[MarkusTeufelberger]

I didn't mean using a different version of each library, but at least a different version of Boost (e.g. all boost 1.65 libraries or all boost 1.69 libraries). Currently this is pinned to a single version:

rules_boost/boost/boost.bzl

Line 231 in 29d1426

"https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.bz2",

[Kernald]

Because of the if on line 224 of that file, you can already override that if you want. Not the cleanest way, but you can copy/paste that http_archive block in your workspace (before calling boost_deps) and change the version there. But yeah taking the version and checksum as an argument for this macro could be a better approach to this.

[reltuk]

Unfortunately, available files change between boost releases...in my experience the included BUILD.boost won't work with Boost versions for which it wasn't written/tested/updated. It's possible that some of the @boost targets would still work though. You're mileage may vary.

I think we would probably need a different approach to writing and maintaining the rules if we wanted to support multiple versions of boost in the same rules_boost commit. Something like an explicit file list per library version, calculated from the modularized boost source tree could maybe work. But that would be a pretty big change in project structure and scope.

[traceon]

Apparently, this suffers from the same issue: bazel-contrib/rules_foreign_cc#510