Switch gen-kconfig to new framework

Also:
- Move companion_* to comp_* to match the kconfig symbols
- Replace bootstrap with former gen-versions.sh
- Fold *.in.2 into their respective first parts; this moves common
  options to the end - if it is undesirable, inclusion of *.in
  can be moved where *.in.2 used to be (but that will also move
  version selection after common options).
- Retire addToolVersion.sh (may later replace with a more
  comprehensive script that tries to download the added tarballs,
  copy the patches and try to apply them, and create a version.desc).

Signed-off-by: Alexey Neyman <stilor@att.net>

1 files changed, 96 insertions, 1 deletions

diff --git a/config/arch/arm.in b/config/arch/arm.in
index 5dbc717d..269310d6 100644
--- a/config/arch/arm.in
+++ b/config/arch/arm.in
@@ -14,6 +14,101 @@
 ## select ARCH_SUPPORTS_WITH_FLOAT if ARCH_32
 ## select ARCH_SUPPORTS_WITH_FPU if ARCH_32
 ## select ARCH_SUPPORTS_SOFTFP if ARCH_32
-##
+
 ## help The ARM architecture, as defined by:
 ## help     http://www.arm.com/
+
+if ARCH_32
+config ARCH_ARM_MODE
+    string
+    default "arm"   if ARCH_ARM_MODE_ARM
+    default "thumb" if ARCH_ARM_MODE_THUMB
+
+choice
+    bool
+    prompt "Default instruction set mode"
+    default ARCH_ARM_MODE_ARM
+
+config ARCH_ARM_MODE_ARM
+    bool
+    prompt "arm"
+    help
+      Defaults to emitting instructions in the ARM mode.
+
+config ARCH_ARM_MODE_THUMB
+    bool
+    prompt "thumb"
+    help
+      Defaults to emitting instructions in the THUMB mode.
+
+endchoice
+
+config ARCH_ARM_INTERWORKING
+    bool
+    prompt "Use Thumb-interworking (READ HELP)"
+    help
+      Excerpt from the gcc manual:
+      
+      > Generate code which supports calling between the ARM and Thumb
+      > instruction sets. Without this option the two instruction sets
+      > cannot be reliably used inside one program. The default is
+      > [not to use interwork], since slightly larger code is generated
+      > when [interwork] is specified.
+      
+      NOTE: Interworking in crosstool-NG is not sell-tested. Use at your
+            own risks, and report success and/or failure.
+
+# Until we only support EABI:
+config ARCH_ARM_ABI_OK
+    def_bool y
+    depends on ! ARCH_ARM_EABI
+    select ARCH_SUPPORTS_WITH_ABI
+
+# Little trick to force EABI *and* always show the prompt
+config ARCH_ARM_EABI_FORCE
+    bool
+    default y if ! OBSOLETE
+    select ARCH_ARM_EABI
+
+config ARCH_ARM_EABI
+    bool
+    prompt "Use EABI"
+    default y
+    help
+      Set up the toolchain so that it generates EABI-compliant binaries.
+      
+      If you say 'n' here, then the toolchain will generate OABI binaries.
+      OABI has long been deprecated, and is now considered legacy.
+
+config ARCH_ARM_TUPLE_USE_EABIHF
+    bool
+    prompt "append 'hf' to the tuple (EXPERIMENTAL)"
+    depends on ARCH_FLOAT_HW
+    depends on ARCH_ARM_EABI    # Until we only support that...
+    default y
+    help
+      Is you say 'y' here, then the tuple for the toolchain will end
+      up with *eabihf, instead of the usual *eabi.
+
+      *eabihf is used to denote that the toolchain *is* using the
+      hard-float ABI, while *eabi is just an indication of using the
+      soft-float ABI.
+
+      Ie. all one can say is:  *eabihf ⊢ hard-float ABI
+
+      Saying 'n' here does *not* impact the ability of the toolchain to
+      generate hard-float instructions with the hard-float ABI. It is a
+      purely cosmetic thing, used by distros to differentiate their
+      hard-float-ABI-using ports from their soft-float-ABI-using ports.
+      (eg. Debian Wheezy and above).
+
+      This is an option, as not all versions of gcc/binutils do support
+      such tuple, and fail to build with *eabihf. Stock gcc version up
+      to, and including 4.7.2 have an issue or another with *eabihf.
+
+      This option is here for the future.
+
+      Say 'n', unless you are trying to fix gcc to properly recognise
+      the *eabihf tuples.
+
+endif