In my Android Studio project, I added the following build type to the build.gradle file:
jnidebug.initWith(buildTypes.debug)
jnidebug {
packageNameSuffix ".jnidebug"
jniDebuggable true
}
The documentation at:
http://tools.android.com/tech-docs/new-build-system/user-guide
says:
For each Build Type, a new matching sourceSet is created, with a
default location of src/<buildtypename>/
But when I resync gradle, the source code folder src/jnidebug never gets created. What am I doing wrong?
The documentation says that for each build type, a source set (which is a logical concept/domain object) is created and configured with a default location. It doesn't say that a source directory is created. You'll probably have to create the directory yourself. (Android Studio could certainly help with that, so perhaps file a feature request.)
Related
I am writing a custom annotation processor in Java which needs to create a file.
It seems to me the best location for that file would be in a new folder inside the Gradle's $buildDir.
For a project without modules, the environment property "user.dir" seems to hold a value I could use.
However, that environment property changes if the project has modules and the gradlew build command is executed either from inside or outside a module.
What is the best approach to actually get in Java the Gradle build directory of the module in which the annotation processor is declared ?
P.S.
I do not want to create that file in the "build/generated" folder (this is what processingEnv.getFiler().createSourceFile(..) does).
You should do it the other way around : choose a location and set it up in your build.gradle
tasks.withType(JavaCompile) {
options.annotationProcessorGeneratedSourcesDirectory = file("your/custom/path")
}
I got some source code and was asked to build it. It was a Gradle project. So I changed to the project directory and ran:
$ gradle clean assemble
and the following error came up:
...
* What went wrong:
A problem occurred evaluating root project 'pcase'.
> Could not get unknown property 'postgresql.jdbc' for root project 'pcase' of type org.gradle.api.Project.
...
There is a settings.gradle file in the project folder too. It contains:
rootProject.name = 'pcase'
I took a look at build.gradle and found lots of occurrences like
${project['x']}
For example:
buildscript {
dependencies {
...
// FlywayDB, JOOQ.
classpath "org.postgresql:postgresql:${project['postgresql.jdbc']}"
classpath "org.flywaydb:flyway-gradle-plugin:${project['flywaydb.plugin.version']}"
classpath "nu.studer:gradle-jooq-plugin:${project['jooq.plugin.version']}"
...
What could be ${project['x']}? Looks like associative array in bash and the build script tries to get the value of the key 'x'.
But I didn't find the place in code where this array would be declared and initialized.
The question is: Is the project buildable or is it better to consult the company that worked at it before me?
From the information provided, the project is perfectly buildable, to some certain extend. First of all, project['a.b.c'] is Groovy syntax to access properties from the project object. They're referred to as project properties.
They can be set via
Project properties via command line: gradle -Ppostgresql.jdbc=x.y.z
System properties via command line: gradle -Dorg.gradle.project.postgresql.jdbc=x.y.z
System properties via gradle.properties: org.gradle.project.postgresql.jdbc=x.y.z
All 3 properties (postgresql.jdbc, flywaydb.plugin.version, jooq.plugin.version) denote the version numbers of the particular build script dependencies. However, which versions to use best is beyond my knowledge. I would certainly consult the respective project websites, Maven artifact search or simply ask the company.
org.postgresql:postgresql is the database JDBC driver and certainly depends on the database version.
org.flywaydb:flyway-gradle-plugin is for database migrations. Try with the latest version.
I wasn't able to find gradle-jooq-plugin on Maven central. It's most likely available on the Gradle Plugin Portal.
I have an Android Studio project which depends on a native shared library. I have created a cmake file to compile the library and I have added a soft link to the shared library inside the android project (in src/main/jniLibs/armeabi). That way when the android project is built, the shared library is included in the package.
Here is the relevant part of build.gradle:
android {
...
externalNativeBuild {
cmake {
path "../cpp/CMakeLists.txt"
}
}
}
The problem is that gradle tries to open the shared library before invoking the instructions to build it.
Information:Gradle tasks [:app:assembleDebug]
Error:Could not list contents of 'app/src/main/jniLibs/armeabi/libfoo.so'. Couldn't follow symbolic link.
How can I invoke the cmake from inside the project and include the library in the project at the same time?
--
EDIT
In the cmake the shared library is built with ExternalProject_Add. Unfortunately gradle doesn't see that target, nor does it see imported shared libraries as targets. So this does not work:
add_library(libfoo SHARED IMPORTED GLOBAL)
add_dependencies(libfoo libactual)
I tried to invoke building the particular target with a gradle config:
defaultConfig {
...
externalNativeBuild {
cmake {
targets "libfoo"
}
}
}
But gradle still doesn't see it and fails with:
Unexpected native build target libfoo. Valid values are:
The valid values are basically an empty list.
Currently I work around this by creating a fictional executable depending on the library.
add_executable(libfoo a.c)
add_dependencies(libfoo libactual)
In my case, I added a new CMake target, but having none was cached somehow (by CMake or Gradle).
Simply close Android Studio, remove the entire build or .build directory, then open Android Studio and build again.
Note that sub-projects have their own separate build directory.
So, you may need to search for the word build, and after ensuring found result is not required, remove them too.
If still not fixed, remember that CMake has it's own separate cache files, which normallay are inside said directories unless you run CMake directly (outside of Android Studio).
I have the following task in my Android build.gradle file which copies my built APK file for me:
/**
* Copies the final release APK into the project root folder.
*/
task copyRelease(type: Copy) {
// define output files exactly to work around a file locking issue
outputs.files.setFrom(file("../app-release.apk"))
from "build/outputs/apk/app-release.apk"
into ".."
}
This has been working for a long time and broke today when doing Android Studio's suggested update:
Android Gradle plugin v2.3.0 (from v2.2.3)
Gradle v3.3 (from v2.14.1)
Running the Grade build now gives the following error on the line outputs.files.setfrom(...):
No signature of method: org.gradle.api.internal.tasks.DefaultTaskOutputs$TaskOutputUnionFileCollection.setFrom() is applicable for argument types: (java.io.File) values: [..\app-release.apk]
Possible solutions: sort()
To summarise, it seems like TaskOutputUnionFileCollection.setFrom() no longer takes File parameters.
But I do not know how to migrate this code to the new version and a look through the source class has not helped me.
I have looked at the Android Gradle plugin Known Issues page as well as the Gradle 3.3. Release Notes, and found no direct reference to this.
I could not find a direct & exact translation of the above code without implementing a workaround. The problem lies in using the root folder of the project for the destination of the copy command.
The workaround was to create a separate folder ..\release and then the following code works fine:
/**
* Copies the final release APK into the project root folder.
*/
task copyRelease(type: Copy) {
from "build/outputs/apk"
into "../release"
include "app-release.apk"
}
Is there a way to link with a library that's not in the current package path.
This link suggests placing everything under the local directory. Our packages are installed in some repository elsewhere. I just want to specify the libpath to it on windows.
authors = ["Me"]
links = "CDbax"
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
But trying cargo build -v gives me
package `hello v0.1.0 (file:///H:/Users/Mushfaque.Cradle/Documents/Rustc/hello)` specifies that it links to `CDbax` but does not have a custom build script
From the cargo build script support guide, it seems to suggest that this should work. But I can see that it hasn't added the path. Moving the lib into the local bin\x68_64-pc-windows-gnu\ path works however.
Update
Thanks to the answer below, I thought I'd update this to give the final results of what worked on my machine so others find it useful.
In the Cargo.toml add
links = "CDbax"
build = "build.rs"
Even though there is no build.rs file, it seems to require it (?) otherwise complains with
package `xxx v0.1.0` specifies that it links to `CDbax` but does not have a custom build script
Followed by Vaelden answer's create a 'config' file in .cargo
If this is a sub crate, you don't need to put the links= tag in the parent crate, even though it's a dll; even with a 'cargo run'. I assume it adds the dll path to the execution environment
I think the issue is that you are mistaking the manifest of your project with the cargo
configuration.
The manifest is the Cargo.toml file at the root of your project. It describes your project itself.
The cargo configuration describes particular settings for cargo, and allow for example to override dependencies, or in your case override build scripts. The cargo configuration files have a hierarchical structure:
Cargo allows to have local configuration for a particular project or
global configuration (like git). Cargo also extends this ability to a
hierarchical strategy. If, for example, cargo were invoked in
/home/foo/bar/baz, then the following configuration files would be
probed for:
/home/foo/bar/baz/.cargo/config
/home/foo/bar/.cargo/config
/home/foo/.cargo/config
/home/.cargo/config
/.cargo/config
With this structure you can specify local configuration per-project,
and even possibly check it into version control. You can also specify
personal default with a configuration file in your home directory.
So if you move the relevant part:
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
to any correct location for a cargo configuration file, it should work.