crosstool-ng/config/global.in

# Overall toolchain configuration: paths, jobs, etc...

# Ah, this option is here to break the dependency tracking, and allow
# dependent option to line-up with the options they depend on ,rather
# than being indented
config FOOBAR
    bool
    default n

menu "Paths and misc options"

comment "Crosstool-ng behavior"

config EXPERIMENTAL
    bool
    prompt "Try features marked as EXPERIMENTAL"
    default n
    help
      If you set this to Y, then you will be able to try very experimental
      features.
      
      Experimental features can be one of:
        - working, in which case you should tell me it is!
        - buggy, in which case you could try patching and send me the result
        - unfinished, in which case you could try hacking it and send me the result
        - non-existant, in which case you could also try hacking it in and send the result

config OBSOLETE
    bool
    prompt "Use obsolete features"
    default n
    help
      If you set this to Y, you will be able to select obsolete features.
      
      Such obsolete features are the use of old kernel headers, old
      gcc versions, etc...

config DEBUG_CT
    bool
    prompt "Debug crosstool-NG"
    default n
    help
      Say 'y' here to get some debugging options

if DEBUG_CT

config DEBUG_CT_PAUSE_STEPS
    bool
    prompt "Pause between every steps"
    default n
    help
      Say 'y' if you intend to attend the build, and want to investigate
      the result of each steps before running the next one.

config DEBUG_CT_SAVE_STEPS
    bool
    prompt "Save intermediate steps"
    default n
    help
      If you say 'y' here, then you will be able to restart crosstool-NG at
      any step.
      
      It is not currently possible to rstart at any of the debug facility.
      They are treated as a whole.

      See docs/overview.txt for the list of steps.

config DEBUG_CT_SAVE_STEPS_GZIP
    bool
    prompt "gzip saved states"
    default y
    depends on DEBUG_CT_SAVE_STEPS
    help
      If you are tight on space, then you can ask to gzip the saved states
      tarballs. On the other hand, this takes some longer time...
      
      To lose as less time as possible, the gzip process is done with a low
      compression ratio (-3), which gives roughly 70% gain in size. Going
      further doesn't gain much, and takes far more time (believe me, I've
      got figures here! :-) ).

endif

comment "Build behavior"

config PARALLEL_JOBS
    int
    prompt "Number of parallel jobs"
    default 1
    help
      Number of jobs make will be allowed to run concurently.
      Set this higher than the number of processors you have, but not too high.
      A good rule of thumb is twice the number of processors you have.
      
      Enter 1 (or 0) to have only one job at a time.

config LOAD
    int
    prompt "Maximum allowed load"
    default 0
    help
      Specifies that no new jobs should be started if there are others jobs
      running and the load average is at least this value.
      
      Makes sense on SMP machines only.
      
      Enter 0 to have no limit on the load average.
      
      Note: only the integer part of the load is allowed here (you can't enter
            0.75 for example).

config NICE
    int
    prompt "Nice level"
    default 0
    range 0 19
    help
      Renices the build process up.

config USE_PIPES
    bool
    prompt "Use -pipe"
    default y
    help
      Use gcc's option -pipe to use pipes rather than temp files when building
      the toolchain.

comment "Paths"

config LOCAL_TARBALLS_DIR
    string
    prompt "Local tarballs directory"
    default ""
    help
      If you have previously downloaded the tarballs, enter the PATH where
      you stored them here.

config PREFIX_DIR
    string
    prompt "Prefix directory"
    default "${HOME}/${CT_TARGET}"
    help
      This is the path the toolchain will run from.

config INSTALL_DIR
    string
#    prompt "Install directory"
    default "${CT_PREFIX_DIR}"
#    help
#      This is the path the target will be installed into.
#      
#      Normally, you would set this to ${CT_PREFIX_DIR}, but if for some reasons
#      you can't write there, you can install somewhere else and have a third
#      person do the install for you.
#      The reason you might also want to install elsewhere is if you are going
#      to package your shinny new toolchain for distribution.

config CUSTOM_PATCH
    bool
    prompt "Use custom patch directory"
    default n
    help
      If you have custom patches that you want to be applied, say 'Y' here and
      enter the path directory below.
      
      Note that you must ensure that the patch directory is arranged the same
      way the official directory is.

config CUSTOM_PATCH_ONLY
    bool
    prompt "Only use custom patches"
    default n
    depends on CUSTOM_PATCH
    help
      Don't apply patches coming with CT-NG, only those patches available in
      the directory below.
      
      If you say 'N' here, then the patches provided with CT-NG will be applied
      first, and then your patches.

config CUSTOM_PATCH_DIR
    string
    prompt "Custom patch directory"
    default ""
    depends on CUSTOM_PATCH
    help
      Enter the custom patch directory here.

config REMOVE_DOCS
    bool
    prompt "Remove documentation"
    default n
    help
      Remove the installed documentation (man and info pages).
      Gains around 8MiB for a uClibc-based, C and C++ compiler.

config INSTALL_DIR_RO
    bool
    prompt "Render the toolchain read-only"
    default n
    help
      Render the directory of the toolchain (and its sub-directories)
      read-only.
      
      Usefull for toolchains destined for production.

comment "Downloading"

config FORCE_DOWNLOAD
    bool
    prompt "Force downloads"
    default n
    help
      Force downloading tarballs, even if one already exists.
      
      Usefull if you suspect a tarball to be damaged.

config ONLY_DOWNLOAD
    bool
    prompt "Stop after downloading tarballs"
    default n
    help
      Only download the tarballs. Exit once it done.
      
      Usefull to pre-retrieve the tarballs before going off-line.

config FOOBAR

comment "Extracting"
    depends on ! ONLY_DOWNLOAD

config FORCE_EXTRACT
    bool
    prompt "Force extractions"
    depends on ! ONLY_DOWNLOAD
    default n
    help
      Force extraction of already exctracted tarballs.
      
      Usefull if you suspect a previous extract did not complete (eg. broken
      tarball), or you added a new set of patches for this component.

config ONLY_EXTRACT
    bool
    prompt "Stop after extracting tarballs"
    depends on ! ONLY_DOWNLOAD
    default n
    help
      Exit after unpacking and patching tarballs.
      
      Usefull to look at the code before doing the build itself.

comment "Logging"

choice
    bool
    prompt "Maximum log level to see:"
    default LOG_INFO

config LOG_ERROR
    bool
    prompt "ERROR"
    help
      The build will be silent.
      Only if there is an error will you see a message.

config LOG_WARN
    bool
    prompt "WARN"
    help
      The same as above, plus warnings.

config LOG_INFO
    bool
    prompt "INFO"
    help
      The same as above, plus informational messages (main steps).

config LOG_EXTRA
    bool
    prompt "EXTRA"
    help
      The same as above, plus extra messages (sub-steps).

config LOG_DEBUG
    bool
    prompt "DEBUG"
    help
      The same as above, plus lots of crosstool-NG debug information.

config LOG_ALL
    bool
    prompt "ALL"
    help
      The same as above, plus all components build messages (very noisy!).

endchoice

config LOG_LEVEL_MAX
    string
    default "ERROR"   if LOG_ERROR
    default "WARN"    if LOG_WARN
    default "INFO"    if LOG_INFO
    default "EXTRA"   if LOG_EXTRA
    default "DEBUG"   if LOG_DEBUG
    default "ALL"     if LOG_ALL

config LOG_SEE_TOOLS_WARN
    bool
    prompt "Warnings from the tools' builds"
    default n
    depends on ! LOG_ERROR
    help
      Treat warnings from the different tools as crosstool-ng warnings.
      If you say 'y' here, then those warnings will be prefixed with
      '[WARN ]' instead of the default '[ALL  ]'.

      You can safely say 'n' here. Those warnings will anyway be
      recorded in the log file (provided you configured one).

      Tools error will always be logged as crosstool-ng errors.

config LOG_PROGRESS_BAR
    bool
    prompt "Progress bar"
    default y
    depends on ! LOG_ALL
    help
      If you say 'y' here, you'll be able to see the elapsed time.
      
      As a bonus, you'll also get a rotating bar (/-\|) showing you
      that the build is not stalled (the bar rotates 1/4 every 10 lines
      of components build log).

      Note that the elapsed time can stall for a little while if a
      component has long commands, as the elapsed time is only updated
      each line.

config LOG_TO_FILE
    bool
    prompt "Log to a file"
    default y
    help
      Save *full* logs to a file. Even log levels you didn't specify above
      will be available in this file. The log file will be named build.log
      and stored in the toolchain prefix dir (set above).

      As a bonus, there is a script in tools/extractConfig.sh that is able
      to extract the configuration of crosstool-NG from the log file.

      Definitely, say Y.

config LOG_FILE_COMPRESS
    bool
    prompt "Compress the log file"
    default n
    depends on LOG_TO_FILE
    help
      Compress the log file once the toolchain is successfully built.

endmenu