CLI flexibility to reduce exponential toolchain file explosion

[headupinclouds]

I've started adding a number of toolchains I need to support based on combinations of : ANDROID_TOOLCHAIN_NAME + ANDROID_NATIVE_API_LEVEL + ANDROID_ABI + etc. There are similar combinations for *nix platforms and ios. This seems headed for an explosion of *.cmake toolchains in the ${POLLY_ROOT} directory. I'm wondering if it would make sense to extend to build.py command line options to provide dynamic toolchain configurations. I suppose that introduces a fair amount of additional complexity to avoid "undefined" toolchains. We would probably need to define a top level ND matrix of valid parameter configurations for each base toolchain (e.g., android.toolchain.cmake, etc.) with appropriate warnings for bad or untested configurations.

@ruslo I'm fairly sure you've already thought through this at some level, but I wanted to post a discussion item here to review options.

[ruslo]

This seems headed for an explosion of *.cmake toolchains in the ${POLLY_ROOT} directory

For now I think about it as "add what you use". So it's limited by common sense. I guess nobody use 25000 toolchains produces by (21 versions of NDK) x (10 ABI) x (15 API) x (8 STL).

I'm wondering if it would make sense to extend to build.py command line options to provide dynamic toolchain configurations

Probably we can automatically generate top *.cmake files from python code: https://github.com/ruslo/polly/blob/master/bin/detail/toolchain_table.py

I'm fairly sure you've already thought through this at some level

Some thoughts I have:

• autocomplete feature: Add autocomplete #15 so users can press <TAB> and see what variants they have:

> build.py --toolchain android-ndk-<TAB>
r10e
r9d
r8e

• some toolchain variants can be managed by Hunter. As you can see we already can set API level in custom config. Also I'm planning to add stl switching - i.e. you can control stlport/gnustl both version and static/shared.

[ruslo]

Probably we can automatically generate top *.cmake files from python code

#31

[xpol]

Yes, Its really needed.
generate the top *.cmake files base on some templates and a list of tool chain names.

[ruslo]

Just for the record the goal doesn't changed but I think about another implementation approach:

For now I think about it as "add what you use". So it's limited by common sense. I guess nobody use 25000 toolchains produces by (21 versions of NDK) x (10 ABI) x (15 API) x (8 STL).

One of the criterion - toolchains used in AppVeyor/Travis CI testing. There can't be 25000 rows in testing matrix hence there will not be 25000 toolchains in Polly. Of course user can generate by himself any number of extra toolchains he needed.

Probably we can automatically generate top *.cmake files from python code

I'm planning to try it in CMake experimental fork. Will think about integration with aliasing feature, plus GUI widget. Just to clarify: user will able to generate toolchains and add it to regular CMake by -DCMAKE_TOOLCHAIN_FILE, for exterimental CMake there will be some sort of builtin toolchains like -DCMAKE_BUILTIN_TOOLCHAIN_FILE=android-ndk-r10e-api-19-armeabi-v7a-neon or with alias cmake -a android.

autocomplete feature

Goes to "aliasing feature" autocompletion.