mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2024-12-19 04:47:52 +00:00
cb0d1fef8c
If you select to debug ct-ng, then you have two new options: - DEBUG_CT_PAUSE_STEPS : pause between every steps, - DEBUG_CT_SAVE_STEPS : save state between every steps. To restart a saved state, just set the RESTART make variable when calling make: - make RESTART=<step_name>
359 lines
9.1 KiB
Plaintext
359 lines
9.1 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
|
|
config FOOBAR
|
|
bool
|
|
default n
|
|
|
|
menu "Paths and misc options"
|
|
|
|
comment "Crosstool 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 by typing:
|
|
make RESTART=<step_nane>
|
|
|
|
where step_name is one of:
|
|
- kernel_hdr
|
|
- binutils
|
|
- libc_hdr
|
|
- cc_core
|
|
- libfloat
|
|
- libc
|
|
- cc
|
|
- libc_fin
|
|
- debug
|
|
|
|
It is not currently possible to rstart at any of the debug facility.
|
|
They are treated a s a whole.
|
|
|
|
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.
|
|
|
|
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 mesage.
|
|
|
|
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 tool builds as CT warnings"
|
|
default n
|
|
depends on ! LOG_ERROR
|
|
help
|
|
Treat warnings fron the different tools as crosstool 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).
|
|
|
|
config LOG_PROGRESS_BAR
|
|
bool
|
|
prompt "Progress bar"
|
|
default n
|
|
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.
|
|
|
|
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
|
|
string
|
|
prompt "Log file"
|
|
default "${CT_PREFIX_DIR}/${CT_TARGET}.log"
|
|
depends on LOG_TO_FILE
|
|
help
|
|
File name into which to put logs.
|
|
|
|
endmenu
|