[cmake-developers] vs-nsight-tegra-generator topic

[Stephen Kelly]

Brad King wrote:

> On 09/16/2014 10:05 AM, Brad King wrote:
>> Please take a look if you are interested in Android development.
> [snip]
> On 09/15/2014 07:04 PM, Stephen Kelly wrote:
>> Brad King wrote:
>>> On 09/10/2014 11:49 AM, Stephen Kelly wrote:
>>>>  target_link_libraries(mylib cmake::android-16)
>>>
>>> Interesting idea.  These could be predefined in the
>>> Platform/Android.cmake
>>> module.  However, I do not think the current ANDROID_API property will
>>> be outdated by such a design
>>
>> Indeed. However, validation of allowed values might be worthwhile even
>> now.
> 
> Steve, what validation should be done for ANDROID_API?  Just that it
> is a decimal integer value?

Apparently, yes:

 http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

Are there any restrictions on how old an android API the tegra system works 
with? I think the SDK has changes significantly at least once during the 
android lifetime. Setting an upper limit on the allowed value might also 
make sense, may not be necessary?

> I think we will also need an ANDROID_ARCH and ANDROID_STL property.
> How should these be validated?

I don't know much about the _ARCH variable. That effectively determines the 
particular sysroot in the NDK to use, right? If you require that the path to 
the NDK be known, then you can validate that the directory exists to 
validate it.

The _STL one I would like to see be generic at least. On any machine I don't 
want to compile my library with libc++ and link it with my executable 
compiled with libstdc++. I'd also want an abstraction for specifying the -
stdlib= option for clang and the 'expanded' -I and -L/-l for GCC. I think 
this came up several times during the compile-features

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9729

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7671

but it was an orthogonal feature. I guess an interface of 
CMAKE_{,CXX_STDLIB} variable/property could pass standard values (libc++ and 
libstdc++) to the -stdlib option of clang and the user could define 
variables like 

 CMAKE_CXX_STDLIB_<COMPILE|LINK>_OPTIONS_<foo>

such as 

 CMAKE_CXX_STDLIB_COMPILE_OPTIONS_stlport
 CMAKE_CXX_STDLIB_LINK_OPTIONS_stlport

in a toolchain file to make it possible to use another stl, or for use with 
GNU.

However, I suspect with your Tegra system one only has to specify the stl 
and you're going to want to solve only that problem with a ANDROID_STL 
property, right :)?

Thanks,

Steve.