3 ms·
Many words and few to the point. tldr: This person likes build-tools (Google's Bazel) that can constrain dependencies to be used only by certain packages, and s
by simpaticoder 1y ago
Many words and few to the point. tldr: This person likes build-tools (Google's Bazel) that can constrain dependencies to be used only by certain packages, and says this documents the project's architecture.
I've always thought of "architecture" as a high-level description of run-time behavior, not a set of compile-time dependency constraints.
- npodbielski 1y agoExactly. I thought that in modern languages and frameworks there are better tools to do that like 'ProjectReference' in .Net. Oh well..
- jmmv 1y agoI have worked with ProjectReference before. How is it different from expressing a cross-module dependency in a Bazel BUILD file? But as I already said in two other comments in this discussion, ProjectReference would be equivalent to what I'm describing in the article, just using language-specific tooling. If you are breaking your solution into various projects and keeping them separate with cross-references among them, you are doing exactly what I was describing already.
- kiitos 1y ago> the build graph -- the very thing that BUILD files define -- is the best place to encode [dependencies] in a programmatic manner. so the thing is that a BUILD file doesn't define the build graph, it approximates it -- the build graph is always defined by language-specific tooling and specifications it's fine that the BUILD file is an approximation! that's as good as you can do, if you want to try to model dep relationships between heterogeneous languages so when we're talking about the dep graph, "using language-specific tooling" isn't a detail you can brush aside, it's a core requirement for correctness, really