Handling native dependencies across different platforms

Old Forum Archive
1

My project uses some native libraries, some are owned by us (and built using the cpp plugin) and others are external. I’ve just been implementing something to help make using them a bit easier and wondered whether;

  • there were any plans in this direction for gradle? * how other people handle this sort of use case?

My problem is that the precise native dependency I need varies according to the platform the jvm is running on so I need a different binary depending on the context I am running. The most common case being;

dev workstation = windows 7 x64 any server environment = linux x64

I’ve tackled this by adding the concept of a NativeDependency, a container for which is added to the project by my plugin. The type is rougly described as follows;

class NativeDependency {
    private final String name
    /** our standard platform */
    NativePlatform defaultPlatform = LINUX_X86_64
    /** the artefact this dependency describes */
    private final ModuleVersionIdentifier artefact
    /** native environments per target environment (DEV etc), used to override {@link #defaultPlatform} */
    private Map<Environment, NativePlatform> nativePlatformByEnv
    /** the configurations this dependency should be applied to */
    List<String> configurations = ['runtime']
}

The instance is constructed like

natives {
    'org.my.company:my-native:1.0' { configurations = ['someotherconfig'] }
}

The plugin then augments the IDE plugin with the right artefact for the DEV env and the usual build with whichever environment is correct for where it needs to run. To make this more general it would need at least;

  • making NativeDependency a first class citizen rather than making some separate thing - some sort of strategy for resolving the platform into some aspect of the dependency (classifier, type whatever… we only rely on a few and their names are “well formed”) - some mechanism for dealing with this type of dependency correctly in the dependency description (ivy.xml, pom etc)

Cheers Matt

2

Hi Matt,

This is something that’s on our radar. We’ve been discussing this on our developer list for some time now. It’s a very thorny problem once you get into it.

We’ve not started concrete work yet, but have started spec’ing out our new model to handle this (see this spec). When we have concrete functionality to test out, we’ll announce it on this forum. In the meantime, there will be plenty of discussion happening on the developer list about this.

In the absence of a fundamental solution in Gradle, your solution looks to be a good interim step.