would like to have some directory structure (a,b,c,sw) each with a build.gradle.
sw would be the root of the multiproject. a would be an executable, b,c would be libs with a depending on b,c static, b depending on c for api.
a,b,c could potentially be pulled in from different scm repositories
goal is to have a,b,c have their project definitions be local to their tree and not in some big honking 10,000 line build.gradle in sw
what would that look like in the gradle files
e.g.
sw: settings.gradle includes …/a,…/b,…/c
a: settings.gradle includes …/b,…/c
build.gradle : project (":a") depends on (":b") …
b: settings.gradle includes …/c
build.gradle : project (":b") depends on (":c") …
It configures all projects using the root build.gradle, but you could easily split that into separate build.gradle files in each sub project’s directory.
Also note, there should only be a settings.gradle file in the root project.
we don’t really want to have real filesystem level root, think of the root and the sub’s all being peer items in various source repositories.
[fetched into some combined local workspace tree. obviously we could script copy move things if we really had to]
we want each sub to have its own build.gradle. think continuous integration build avoidance. right now we touch the ‘root’ build.gradle and when its committed 80 jobs fire.
goal is to have somewhat loose coupling so the sub’s could be reused independently of the current ‘root’, e.g. separate project teams in a product line ecosystem.
As this is native (c++) we have no other strategy in place (e.g. header/library repository) to share projects at some level other than source. and since its c++ each project team could (insanely) choose different compile flags or cross compilers…
OK, since my native knowledge is limited there might be a better way to handle your requirements, but have you done any experiments with the upcoming composite build feature? You’ll want to be using the latest version of Gradle in order to use it.
ProjectA would be your “root” project, and its settings.gradle includes the other project builds.
I personally haven’t had a chance to try composite builds so I can’t really judge how well it will work for you.
It sounds like the artifact of a library is the source code itself, since you say you can’t re-use binaries easily, due to downstream consumers wanting to use different compiler flags, etc. So maybe a half-decent compromise is to publish the source as a versioned zip/tar into an artifact repository. Then projects that consume those libraries can resolve the dependencies and extract the source as part of the project. If the libraries have upstream dependencies then you could model that with dependencies on the published artifacts (assuming you’re publishing the packaged source to a repository like Maven or Ivy).
What does a CI job look like for your libraries? I’m curious what, if any, meaningful work can be done on a library that the downstream consumers are going to recompile anyways (especially since they might compile it in N different ways). Seems like you wouldn’t be able to do too much valuable unit testing, etc, but that’s what I’m interested in hearing about.