I have a gradle c/cpp project where it has rootProject/project/subProject
In my root build.gradle I have
ext.libFolder = rootDir.toString + ‘/lib/’
subprojects {
build.doLast {
from fileTree ( buildDir.getCanonicalPath() ).files
into rootProject.ext.libFolder
include ‘.so’
include '.a’
}
}
This works perfectly when I do: gradle build but if I do gradle :project:subProject:build it does not work… What do I need to change to make this work no matter how I call the build task?
On a side note we are trying to make all subProject build.gradle files as bare minimal as possible, simple as possible, and structurally the same as possible, as we have over 780 of them.
I tried something similar with a Java multiproject build and it worked fine. There are a few problems in your example, so I’d expect the build to throw an error. Here’s what worked for me:
ext.libFolder = new File(rootDir, 'lib')
subprojects {
build.doLast {
from fileTree ( buildDir.getCanonicalPath() )
into rootProject.libFolder
include '*.so'
include '*.a'
}
}
Well, the equivalent of that anyway. To run a subproject, you should be using
gradle :subProject:build
I’m not sure what the :project prefix you’re using is about.
The reason the .files is on the end of the fileTree is to flatten the directory, without it the directory structure is not flattened. As to the copy task it works as is but is not working only when you call build in someway that is not simply build. Someone on stack recommend putting the build.doLast inside of a afterEvaluate but that didn’t work either.
Edit: As to the :project:subProject:build the way the project is setup is like so:
Good point about the .files vs fileTree(). And thanks for clearing up the project path stuff.
Unfortunately I still can’t reproduce this behaviour. Have you tried with a different version of Gradle? I tried with 2.6 and 2.9. Have you tried adding a log or println() statement in the doLast() to see whether it’s actually being called? If it is being called, perhaps the paths are incorrect somehow.
I have figured out what is going on. When a task like :_QT_CORE:QT_MAIN:build is ran it runs only the compile task of projects it depends on not their build task. So for example :_QT_CORE:QT_MAIN depends on :_CORE:THREADING among other things. If a providing project has had a change and a dev has not ran a gradle build then they will have libraries that are not up-to-date. This leads to problems.