On Sun, 16 Dec 2018 00:17:55 +0000, Paul Backus wrote: > On Wednesday, 12 December 2018 at 22:41:50 UTC, H. S. Teoh wrote: >> It's time we came back to the essentials. Current monolithic build >> systems ought to be split into two parts: [...] > You're missing (0) the package manager, which is probably the biggest > advantage "monolothic" build tools like dub, cargo, and npm have > compared to language-agnostic ones like make.
If I were to make a new build tool and wanted package manager integration, I'd choose Maven as the backend. This would no doubt be more frustrating than just making my own, but there would hopefully be fewer bugs on the repository side. (I might separately make my own Maven-compatible backend.) > There's something important you're glossing over here, which is that, in > the general case, there's no single obvious or natural way to compose > two DAGs together. You do it like Bazel. In Bazel, you have a WORKSPACE file at the root of your project. It describes, among other things, what dependencies you have. This might, for instance, be a git URL and revision. All this does is expose that package's build rules to you. Separately, you have build rules. Each build rule can express a set of dependencies on other build rules. There's no difference between depending on a rule that your own code defines and depending on one from an external dependency. It might be appropriate to have a hint on DAG nodes saying that this is the default thing that you should probably depend on if you're depending on the package. A lot of projects only produce one artifact for public consumption.
