Fixed
Status Update
No update yet.
Comments
jo...@google.com
What's happening is that the .hpp file (which is normal a header file) is being compiled in CMake with:
add_library( # Sets the name of the library.
native-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
src/main/cpp/native-lib.cpp src/main/cpp/native-lib.hpp)
The add_library command is for adding sources in CMake not for headers files. This is causing a cascade failure into Android Studio.
We shouldn't crash so I'll fix that but the root issue is that CMake doesn't intend header files to be passed into add_library
add_library( # Sets the name of the library.
native-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
src/main/cpp/native-lib.cpp src/main/cpp/native-lib.hpp)
The add_library command is for adding sources in CMake not for headers files. This is causing a cascade failure into Android Studio.
We shouldn't crash so I'll fix that but the root issue is that CMake doesn't intend header files to be passed into add_library
je...@gmail.com
I think having headers listed in add_library is quite common because this is an easy to way get the headers listed in IDEs (that is for general CMake usage, not necessarily Android Studio development).
The CMake documentation (https://cmake.org/cmake/help/latest/command/add_library.html ) even says (in the object libraries section):
"Object libraries may contain only sources that compile, header files, and other files that would not affect linking of a normal library (e.g. .txt)"
That is for object libraries rather than shared libraries, but still, this is quite a common idiom to put those headers in add_library even for shared libs. You can find heaps of reference on google.
Glad you are having a look at this though! Thanks!
The CMake documentation (
"Object libraries may contain only sources that compile, header files, and other files that would not affect linking of a normal library (e.g. .txt)"
That is for object libraries rather than shared libraries, but still, this is quite a common idiom to put those headers in add_library even for shared libs. You can find heaps of reference on google.
Glad you are having a look at this though! Thanks!
Description
Version of Gradle Plugin: 3.2.0-alpha01
Version of Gradle: gradle-4.4.1
Version of Java: 1.8.0_152-release-1024-b01 x86_64
OS: Mac OS X 10.12.6
Steps to Reproduce:
1. Open attached project
2. On line 24 of native_lib/build.gradle, the external CMake version is defined but commented out. Gradle syncing should succeed.
3. If you remove the comment for version defining, Gradle sync will fail with the error at the bottom of this report.
4. Further investigation has seen that adding header files to the CMakeLists.txt will cause Gradle syncing to fail with the same error. You can see this behaviour by removing src/main/cpp/native-lib.hpp from line 20 of CMakeLists.txt. Syncing succeeds when this is removed.
5. This behaviour is not seen when rolling back to version 3.0.1 of the Gradle plugin.
Error displayed:
Gradle sync failed: Cause: com.intellij.openapi.externalSystem.model.ExternalSystemException:
at org.jetbrains.plugins.gradle.model.ProjectImportAction.addExtraProject(ProjectImportAction.java:141)
at org.jetbrains.plugins.gradle.model.ProjectImportAction.execute(ProjectImportAction.java:78)
at org.jetbrains.plugins.gradle.model.ProjectImportAction.execute(ProjectImportAction.java:40)
at org.gradle.tooling.internal.consumer.connection.InternalBuildActionAdapter.execute(InternalBuildActionAdapter.java:80)
at org.gradle.tooling.internal.provider.runner.ClientProvidedBuildActionRunner.buildResult(ClientProvidedBuildActionRunner.java:77)
at org.gradle.tooling.internal.provider.runner.ClientProvidedBuildActionRunner.access$000(ClientProvidedBuildActionRunner.java:37)
at org.gradle.tooling.internal.provider.runner.ClientProvidedBuildActionRunner$1.buildFinished(ClientProvidedBuildActionRunner.java:56)
at sun.reflect.GeneratedMethodAccessor157.invoke(Unknown Source)