menu "Toolchain options"

 comment "General toolchain options"

 config USE_SYSROOT

     bool

     prompt "Use sysroot'ed toolchain"

     default y

     help

       Use the 'shinny new' sysroot feature of gcc: libraries split between

       prefix/target/sys-root/lib and prefix/target/sys-root/usr/lib

       You definitely want to say 'Y' here. Yes you do. I know you do. Say 'Y'.

 config SYSROOT_DIR_PREFIX

     string

     prompt "sysroot prefix dir (READ HELP)" if ! BACKEND

     depends on USE_SYSROOT

     default ""

     help

       *

       * Unless you realy know you need that, leave it empty!

       *

       This string will be interpreted as a directory component to be added

       to the sysroot path, just before the actual sysroot directory.

       In fact, the sysroot path is constructed as:

         ${CT_PREFIX_DIR}/${CT_TARGET}/${CT_SYSROOT_DIR_PREFIX}/sys-root

 config STATIC_TOOLCHAIN

     bool

     prompt "Build Static Toolchain (EXPERIMENTAL)"

     depends on EXPERIMENTAL

     default n

     help

       Build static host binaries.

       If you wish to move the toolchain to another host, and you are not

       confident that this host has the required versions of system libs, then

       you can say 'Y' here, and all the host tools will be linked staticaly.

       The impacted tools are:

         - the cross-gdb

       The default is 'N', to build dynamicaly-linked host binaries.

       NOTE: this has no connection to whether the target libraries will be

       dynamic or static. This only applies to the tools themselves.

 comment "Tuple completion and aliasing"

 config TARGET_VENDOR

     string

     prompt "Tuple's vendor string"

     default "unknown"

     help

       Vendor part of the target tuple.

       A tuple is of the form arch-vendor-kernel-system.

       You can set the second part, vendor, to whatever you see fit.

       Use a single word, or use underscores "_" to separate words.

       Use neither dash nor space, as it breaks things.

       Keep the default (unknown) if you don't know better.

 config TARGET_ALIAS_SED_EXPR

     string

     prompt "Tuple's sed transform"

     default ""

     help

       Normaly, you'd call your toolchain components (especially gcc) by

       prefixing the target tuple followed by a dash and the component name

       (eg. armeb-unknown-linux-uclibc-gcc).

       You can enter here a sed expression to be applied to ${CT_TARGET} to

       create an alias for your toolchain.

       For example, "s/${CT_TARGET_VENDOR}/foobar/" (without the double quotes)

       will create the armeb-foobar-linux-uclibc alias to the above-mentioned

       toolchain.

       You shouldn't need to enter anything here, unless you plan to manually

       call the tools (autotools-based ./configure will use the standard name).

 config TARGET_ALIAS

     string

     prompt "Tuple's alias"

     default ""

     help

       Normaly, you'd call your toolchain components (especially gcc) by

       prefixing the target tuple followed by a dash and the component name

       (eg. armeb-unknown-linux-uclibc-gcc).

       You can enter a shortcut here. This string will be used to create

       symbolic links to the toolchain tools (eg. if you enter "foo-bar" here,

       then gcc for your toolchain will also be available as "foo-bar-gcc" along

       with the original name).

       You shouldn't need to enter anything here, unless you plan to manually

       call the tools (autotools-based ./configure will use the standard name).

 comment "Toolchain type"

 choice

     bool

     prompt "Type"

     default CROSS

 config NATIVE

     bool

     prompt "Native       (NO CODE!) (EXPERIMENTAL)"

     depends on EXPERIMENTAL

     help

       Build a native toolchain.

       See docs/overview.txt

 config CROSS

     bool

     prompt "Cross"

     help

       Build a cross-toolchain.

       See docs/overview.txt

 config CROSS_NATIVE

     bool

     prompt "Cross-native (NO CODE!) (EXPERIMENTAL)"

     depends on EXPERIMENTAL

     help

       Build a cross-native toolchain.

       See docs/overview.txt

 config CANADIAN

     bool

     prompt "Canadian     (EXPERIMENTAL)"

     depends on EXPERIMENTAL

     help

       Build a canadian-toolchain.

       See docs/overview.txt

 endchoice

 config TOOLCHAIN_TYPE

     string

     default "native"        if NATIVE

     default "cross"         if CROSS

     default "cross-native"  if CROSS_NATIVE

     default "canadian"      if CANADIAN

 comment "Build system"

 config BUILD 

     string

     prompt "|  Tuple        (READ HELP!)"

     default ""

     help

       Canonical name of the machine building the toolchain.

       You should leave empty, unless you really now what you're doing.

 config BUILD_PREFIX

     string

     prompt "|  Tools prefix (READ HELP!)"

     default ""

     help

       If you have your *build system* tools in a weird location, and/or

       they have an unusual prefix, enter it here.

       Usually, you should leave that empty!

       Eg.:

         If your *build* gcc is /opt/build-tools/bin/weird-gcc then you

         should enter:

             /opt/build-tools/bin/weird-

         If your *build* gcc is /opt/build-tools/bin/weird-gcc and

         /opt/build-tools/bin is in your PATH, you should enter:

             weird-

         If your *build* gcc is /opt/build-tools/bin/gcc then you

         should enter (do not forget to add the trailing '/'):

             /opt/build-tools/bin/

 config BUILD_SUFFIX

     string

     prompt "|  Tools suffix (READ HELP!)"

     default ""

     help

       If your *build system* tools have an unusual suffix, enter it

       here.

       Usually, you should leave that empty!

       Eg.:

         If your 'default' gcc is gcc 4.3.1, but you also have gcc-3.4.2

         installed as gcc-3.4, then you should enter:

             -3.4

       It can happen that some of the tools have a suffix, when others

       don't, eg. you can have 'gcc-3.4' and 'ar'. crosstool-NG accounts

       for that by checking the tools without the suffix in case it can

       not find some of the tool.

 if CANADIAN

 comment "Host system"

 config HOST

     string

     prompt "|  Tuple        (READ HELP!)"

     default ""

     help

       Canonical name of the machine running the toolchain.

 config HOST_PREFIX

     string

     prompt "|  Tools prefix (READ HELP!)"

     default ""

     help

       If you have your *host system* tools in a weird location, and/or

       they have an unusual prefix, enter it here.

       Usually, you should leave that empty!

       Eg.:

         If your *host* gcc is /opt/host-tools/bin/weird-gcc then you

         should enter:

             /opt/host-tools/bin/weird-

         If your *host* gcc is /opt/host-tools/bin/weird-gcc and

         /opt/host-tools/bin is in your PATH, you should enter:

             weird-

         If your *host* gcc is /opt/host-tools/bin/gcc then you

         should enter (do not forget to add the trailing '/'):

             /opt/host-tools/bin/

 config HOST_SUFFIX

     string

     prompt "|  Tools suffix (READ HELP!)"

     default ""

     help

       If your *host system* tools have an unusual suffix, enter it

       here.

       Usually, you should leave that empty!

       Eg.:

         If your 'default' gcc is gcc 4.3.1, but you also have gcc-3.4.2

         installed as gcc-3.4, then you should enter:

             -3.4

       It can happen that some of the tools have a suffix, when others

       don't, eg. you can have 'gcc-3.4' and 'ar'. crosstool-NG accounts

       for that by checking the tools without the suffix in case it can

       not find some of the tool.

 endif # CANADIAN

 if CROSS_NATIVE || CANADIAN

 comment "Target system"

 config TARGET_PREFIX

     string

     prompt "|  Tools prefix (READ HELP!)"

     default ""

     help

       If you have your *target system* tools in a weird location, and/or

       they have an unusual prefix, enter it here.

       Usually, you should leave that empty!

       Eg.:

         If your *target* gcc is /opt/target-tools/bin/weird-gcc then you

         should enter:

             /opt/target-tools/bin/weird-

         If your *target* gcc is /opt/target-tools/bin/weird-gcc and

         /opt/target-tools/bin is in your PATH, you should enter:

             weird-

         If your *target* gcc is /opt/target-tools/bin/gcc then you

         should enter (do not forget to add the trailing '/'):

             /opt/target-tools/bin/

 config TARGET_SUFFIX

     string

     prompt "|  Tools suffix (READ HELP!)"

     default ""

     help

       If your *target system* tools have an unusual suffix, enter it

       here.

       Usually, you should leave that empty!

       Eg.:

         If your 'default' gcc is gcc 4.3.1, but you also have gcc-3.4.2

         installed as gcc-3.4, then you should enter:

             -3.4

       It can happen that some of the tools have a suffix, when others

       don't, eg. you can have 'gcc-3.4' and 'ar'. crosstool-NG accounts

       for that by checking the tools without the suffix in case it can

       not find some of the tool.

 endif # CROSS_NATIVE || CANADIAN

 endmenu