2

Using the c plugin, one can specify executables and libraries. I'm using a string tag to specify a library with an OS specific name (later used in a JNI setup).

import org.apache.commons.lang3.SystemUtils as SU

buildscript {
        repositories {
                mavenCentral()
        }
        dependencies {
                classpath 'org.apache.commons:commons-lang3:3.3.2'
        }
}

def osString = SU.IS_OS_LINUX ? "linux" : (SU.IS_OS_MAC_OSX ? "macosx" : SU.IS_OS_WINDOWS ? "windows" : "")
assert osString

That is to get the OS string. Here the declaration of the library:

libraries {
    "diaf-${osString}" {}
}

When running

gradle tasks

on a linux box, one of the tasks will be "diaf-linuxSharedLibrary"

How does one get a handle to the output file of the task (to be used in another task)? In this case libdiaf-linux.so? Without resorting to hard coded paths as in

def path = "${buildDir}/build/binaries/diaf-linuxSharedLibrary/libdiaf-linux.so"

?

mvniekerk
  • 69
  • 8

1 Answers1

1

It seems that the libraries are always created under the same location - see here for the details - You need to hardcode only part of the path.

Unfortunately I haven't tested it - don't know how, to be honest.

EDIT

Below you can find a sample script (created after digging through gradle sources), that prints tasks and output files. I see that building native libraries is organised completely different than other plugins. Hopes it helped you somehow:

apply plugin: 'c'

libraries {
    hello {}
}

binaries.withType(SharedLibraryBinarySpec) { 
   println it.sharedLibraryFile
   println it.tasks
}

binaries.withType(StaticLibraryBinarySpec) { 
   println it.staticLibraryFile
   println it.tasks
}

You can also find some sample under $GRADLE_HOME/samples/native-binaries/.

Opal
  • 81,889
  • 28
  • 189
  • 210
  • http://www.gradle.org/docs/current/javadoc/org/gradle/api/tasks/TaskOutputs.html Looking for something similar to be used in native libraries/executable tasks – mvniekerk Jan 06 '15 at 15:39
  • Yes, I know about task outputs and also was looking for something like that - but haven't found. Will also have a look later on. But as you can see for given component name it's not difficult to construct the output file: `${project.buildDir}/binaries/${component.name}Executable/${component.name}` – Opal Jan 06 '15 at 15:45
  • Hard coding paths... `tasks.findByName("diaf-${osString}SharedLibrary").outputs.hasOutput` returns false. `tasks.findByName("diaf-${osString}SharedLibrary").output.files.files` returns zero array. So, it seems like the C plugin doesn't declare output files. Bug? – mvniekerk Jan 06 '15 at 15:50
  • It seems that it isn't, I was trying in the same way, but I wouldn't say that this is a bug. Maybe it just works in a different manner. – Opal Jan 06 '15 at 15:54
  • `SharedLibrary` and `StaticLibrary` tasks are *lifecycle tasks* - such task does not define outputs but is a kind of task that is used to define dependency on it. For instance `check` from `java` plugin task is a kind of such task. – Opal Jan 06 '15 at 19:24
  • Ok, then to find which sub-task publishes the output files then. linkDiaf-linuxSharedLibrary? – mvniekerk Jan 06 '15 at 22:32
  • 1
    Found it - `tasks.findByName("linkDiaf-${osString}SharedLibrary").outputs.files.files` is an array of two java.lang.File objects, one the output directory and the last one the actual .so file. – mvniekerk Jan 06 '15 at 22:35
  • 1
    Marked your edited answer as the answer for it also gives the File to the output binaries. – mvniekerk Jan 06 '15 at 22:39