To give a bit of the progression we’re going through
- We have dependency management for the JVM (Maven/Ivy) working for Java/Groovy/Scala projects using configurations and a
dependencies {}
block (what you’ll see most Gradle build files using) - All of the native plugins use the software component model
- Dependency management only exists in the native plugins through the Prebuilt libraries mechanism and project dependencies (nothing transitive or external through Maven/Ivy).
- We’re implementing JVM plugins on top of the software component model (Android will use this too)
- For the JVM plugins, we need to have dependency management on par with what we already had. So we’re bringing that into the software component model first for the JVM plugins. You can already see some of that in the ‘javaLibraryPlugin’ samples.
- For the native plugins, the plan is to take advantage of the dependency management brought in by the JVM work. We think a lot of that is going to be similar to the work we’re doing for JDK9 and modular JDK/Jigsaw. JVM modules have a similar idea of exporting dependencies or not.
So, we know we need to do something here, but it has to happen after the JVM work. This is all good information for when it comes time to plan what we’re going to do. e.g., I’d love to be able to do something like (this is just something I have in mind, not necessarily what we’ll do):
model {
components {
lib(NativeLibrarySpec) {
api {
exports 'LIB_MACRO_FOO', 'LIB_MACRO_BAR'
exports 'lib/include'
exports 'log4cxx'
}
macros {
define 'LIB_MACRO_FOO'
define 'LIB_MACRO_BAR', 0
}
dependencies {
shared library 'log4cxx' // log4cxx is defined elsewhere in a PrebuiltLibraries, from what's on the system, pkg-config, etc.
}
}
exe(NativeExecutableSpec) {
dependencies {
shared library 'lib'
// exe automatically gets compiler args for defining LIB_MACRO_FOO and LIB_MACRO_BAR
// links against 'lib' and 'log4cxx'
// and gets 'lib/include' added as an include path
}
}
}
}