Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake toolchain file does not support standalone toolchains #623

Closed
brian-armstrong opened this issue Jan 22, 2018 · 8 comments
Closed

CMake toolchain file does not support standalone toolchains #623

brian-armstrong opened this issue Jan 22, 2018 · 8 comments

Comments

@brian-armstrong
Copy link

The official CMake toolchain does not appear to have any support for standalone toolchains, and more broadly, does not seem to support building libraries which have dependencies which also must be built.

If you compare the NDK's CMake toolchain to the previous best community maintained toolchain ( https://github.com/chenxiaolong/android-cmake/blob/0bcc869b744561245cdaef74b14f3fc73aea0fe7/android.toolchain.cmake ) you can see that the community file supported ANDROID_STANDALONE_TOOLCHAIN which set up everything needed to work out of the standalone toolchain. This is especially useful as it allows a unified sysroot for the arch and API.

Without this support, it seems difficult if not impossible to use the CMake setup to build a library which depends on another library. With CMAKE_FIND_ROOT_PATH_MODE_LIBRARY set to ONLY, CMake ignores CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH. The user could attempt to override this with CMAKE_FIND_ROOT_PATH_MODE_LIBRARY="BOTH" but this has other nasty side effects like leaking host paths into the search list. Generally, this should be avoided and typically doesn't work.

The best option here would be to add support for standalone toolchains. Failing that, the toolchain file should create a new option for user-supplied search paths and then append them to the root paths.

@alexcohn
Copy link

As far as I understand, there is a not-so-long-term goal to get rid of NDK standalone toolchain. The idea is to let NDK distribution be used as a toolchain with no need to special API- and ARCH- dependent configuration.

@brian-armstrong
Copy link
Author

That seems like a good plan. Since that is the case, the latter option I mentioned, about adding user-specified paths to the root path, would be the way to go.

@DanAlbert
Copy link
Member

I'm missing something. Why do you need standalone toolchain support for the CMake toolchain file? The purpose of the toolchain file is to make a standalone toolchain unnecessary. If you want to use an NDK standalone toolchain with CMake, just skip the toolchain file:

$ cmake \
    -DCMAKE_C_COMPILER=$STANDALONE_TOOLCHAIN/bin/clang \
    -DCMAKE_CXX_COMPILER=$STANDALONE_TOOLCHAIN/bin/clang++ \
    ...

@brian-armstrong
Copy link
Author

@DanAlbert That seems rather cumbersome and likely to miss subtle required cflags and include dirs. The toolchain file should hide the cross compiler details from the invoke

At any rate, standalone toolchains aside, the CMake toolchain file lacks any way to include additional dependency locations, as I've stated. Without that, it is useless for building projects with depdencies on other projects.

@DanAlbert
Copy link
Member

@DanAlbert That seems rather cumbersome and likely to miss subtle required cflags and include dirs. The toolchain file should hide the cross compiler details from the invoke

I agree, which is why I'd recommend using the CMake toolchain file without a standalone toolchain. Like I said, I do not understand why these two things need to be used together. Could you explain the use case?

At any rate, standalone toolchains aside, the CMake toolchain file lacks any way to include additional dependency locations, as I've stated. Without that, it is useless for building projects with depdencies on other projects.

Can you provide an example? I'm not very familiar with CMake.

@DanAlbert
Copy link
Member

Closing for lack of a repro case. Will reopen if we get something actionable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
@DanAlbert @alexcohn @brian-armstrong and others