[cmake-developers] Android variables

[Florent Castelli]

On 12/11/2016 13:35, Ruslan Baratov wrote:
> On 12-Nov-16 19:09, Florent Castelli wrote:
>> On 12/11/2016 06:53, Ruslan Baratov wrote:
>>> On 12-Nov-16 08:21, Florent Castelli wrote:
>>>> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
>>>>> Hi,
>>>>>
>>>>> I wonder if it's possible to introduce next variables describing 
>>>>> Android
>>>>> tools:
>>>>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that 
>>>>> will
>>>>> contain the path to preprocessor. Example:
>>>>>    * CMAKE_CXX_COMPILER =
>>>>> <ndk-root>/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ 
>>>>>
>>>>>
>>>>>    * CMAKE_C_PREPROCESSOR =
>>>>> <ndk-root>/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp 
>>>>>
>>>>>
>>>>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
>>>>> variable mean but it's an important part of move from taka-no-me
>>>>> toolchain to CMake 3.7. I guess it's like
>>>>>    * CMAKE_CXX_COMPILER =
>>>>> <ndk-root>/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ 
>>>>>
>>>>>
>>>>>
>>>>> Of course if I'm not missing something and they are not already
>>>>> somewhere :)
>>>>>
>>>>> Ruslo
>>>> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
>>> I have no idea and not planning to test it because the old code was
>>> using `cpp` preprocessor and I see no point of changing it.
>> Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E" 
>> locally and it will work with GCC-like compilers.
>> That's a more robust way to call it as there is no 
>> CMAKE_C_PREPROCESSOR standard value in any CMake file.
>> Nobody should call "cpp" manually anymore, but use the compiler 
>> driver instead to do it for you.
>>
>> That's why there's no standard CPP variable in CMake, it's not needed 
>> at all.
>> For the same reasons, you rarely have to call the linker directly, 
>> it's usually done through the compiler driver.
> Just like I said I'm not using it - this variable needed for 3rd party 
> package. I have no idea how it was used, the only thing I know is that 
> if I remove this variable the package stop working.
Then just set it yourself as I said. You don't even need 3.7.0, you can 
just override it in the current version of CMake and previous toolchain 
you used. The 3rd party package using it should still work.
Use small incremental steps, in order to migrate. It will be easier.

>
>>
>>>> Calling it directly is kind of dangerous though since you will
>>>> probably be missing the proper language information and other options
>>>> that might affect the predefined preprocessor defines.
>>> I'm not calling it directly, it was used by `configure` script of 
>>> 3rd party.
>>>
>>>> gcc has different binaries for different target archs and has some
>>>> defines baked in, but this won't apply to Clang that uses only one
>>>> binary and a target triple.
>>> For clang based android toolchain the 
>>> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
>>> variable points to the directory with gcc, so it will find `cpp`
>>> preprocessor too. I don't know if it's good or bad :)
>>
>> I think that's an implementation detail you shouldn't rely on. The 
>> compilers in the NDK are changing, GCC is deprecated and you 
>> shouldn't expect that.
>> Clang is mostly self contained and using very little from the GCC 
>> distribution (binutils), it will be gone at some point, so you should 
>> be ready for the future.
> My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't 
> bother about the destiny of GCC distribution. When this stuff will 
> change the problems will appear in both taka-no-me and CMake 3.7+.
Well, you should care as the cpp program will likely disappear and you 
will need other means to preprocess anything directly (gcc/clang -E).
Better do it now and break one of the last dependency you have and 
migrate away from old custom variables.

>
>>
>> If you're updating CMake and changing the toolchain file, then I 
>> would expect that some work has to be done, including making changes 
>> to the invocation of a 3rd party script that is using custom 
>> variables from the old toolchain.
> There is a tricky part about that. I do define variables like 
> CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me back 
> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But 
> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after** 
> toolchain processed hence I can't use such variable in toolchain to 
> create my custom variables. So if we want to have everything play nice 
> this should be defined in CMake.
Why do you need that variable to be defined in the toolchain? It 
shouldn't be a problem to define it outside of it or just before you use 
the 3rd party package that is using it.

>
>> Overall, I consider that taka-no-me Android toolchain to be tech 
>> debt. It hasn't been updated for a long time, doesn't work with 
>> recent NDK (unless you resort to use a standalone toolchain), locks 
>> people with some custom variables making them believe they are 
>> standard and has tons of other small bugs and issues.
>> I understand its appeal for most people, but to me, it has caused 
>> more trouble than help.
> Just like I said before, those variables needed in 3rd party tools 
> which is not related neither to CMake nor to taka-no-me toolchain. I 
> see no point of discussing issues you have with taka-no-me toolchain.
So the content of the variables is needed by the 3rd party tools, but 
the variables are used by your script initially, so it's your 
responsibility to pass another content, like the one I suggested.

>
>> It could have been done so much better.
> It's open source world. From my opinion every question like "why it's 
> not so good?" should really be "why I'm not improving it?" or "why I'm 
> not doing something better?".
>
The problem is that the owner abandoned it and isn't answering to issues 
or merging any pull request.
Sure people can fork it, but they will likely not be found by users. 
People who didn't check the PRs on the project are probably stuck at 
some older version of the NDK, inhibiting progress.

> Ruslo 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20161112/42e88033/attachment-0001.html>