menu "Toolchain options"

comment "General toolchain options"

config FORCE_SYSROOT

    bool

    default y if !OBSOLETE

    default n if OBSOLETE

    select USE_SYSROOT

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/sysroot/lib and prefix/target/sysroot/usr/lib

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

config SYSROOT_NAME

    string

    prompt "sysroot directory name"

    depends on USE_SYSROOT

    default "sysroot"

    help

      Enter the base name of the sysroot directory. Usually, this simply

      is 'sysroot' (the default) or 'sys-root'.

      You are free to enter anything here, except for spaces, and '/'

      (see SYSROOT_DIR_PREFIX, below). If you leave this empy, then the

      default 'sysroot' is used.

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}/${CT_SYSROOT_NAME}

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 GNU binutils

        - 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/6 - Toolchain types.txt"

config CROSS

    bool

    prompt "Cross"

    help

      Build a cross-toolchain.

      See: "docs/6 - Toolchain types.txt"

config CROSS_NATIVE

    bool

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

    depends on EXPERIMENTAL

    help

      Build a cross-native toolchain.

      See: "docs/6 - Toolchain types.txt"

config CANADIAN

    bool

    prompt "Canadian     (EXPERIMENTAL)"

    depends on EXPERIMENTAL

    help

      Build a canadian-toolchain.

      See: "docs/6 - Toolchain types.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