crosstool-ng/config/global.in
2007-07-13 12:15:53 +00:00

375 lines
9.7 KiB
Plaintext

# 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
# Use it to intersperse two config options depending one on the other,
# but don't want the second to be indented (for example because you have
# a comment between the two to separate them). See DOWNLOAD and EXTRACT
# options to see how it is used.
config FOOBAR
bool
default n
menu "Paths and misc options"
comment "crosstool-NG behavior"
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 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 BROKEN
bool
prompt "Try broken stuff"
default n
depends on EXPERIMENTAL
help
Select this if you want to _debug_ broken stuff.
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 crosstool-NG, only those patches available
in the directory below.
If you say 'N' here, then the patches provided with crosstool-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
if ! ONLY_DOWNLOAD
comment "Extracting"
config FORCE_EXTRACT
bool
prompt "Force extractions"
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"
default n
help
Exit after unpacking and patching tarballs.
Usefull to look at the code before doing the build itself.
endif # ! ONLY_DOWNLOAD
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