mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2024-12-21 21:57:48 +00:00
8a2b17ab5e
- use ports addon even when installing headers, - use optimisation (-O) when installing headers, to avoid unnecessary warnings (thanks Robert P. J. DAY for pointing this out!), - lowest kernel version to use is only X.Y.Z, not X.Y.Z.T, - a bit of preparations for NPTL (RSN I hope), - fix fixing the linker scripts (changing the backup file is kind of useless and stupid); Shut uClibc finish step: there really is nothing to do; Add a patch for glibc-2.3.6 weak aliases handling on some archs (ARM and ALPHA at least); Did not catch the make errors: fixed the pattern matching in scripts/functions; Introduce a new log level, ALL: - send components' build messages there, - DEBUG log level is destined only for crosstool-NG debug messages, - migrate sub-actions to use appropriate log levels; Update the armeb-unknown-linux-gnu sample: - it builds! - uses gcc-4.0.4 and glibc-2.3.6, - updated to latest config options set.
321 lines
8.3 KiB
Plaintext
321 lines
8.3 KiB
Plaintext
# Overall toolchain configuration: paths, jobs, etc...
|
|
|
|
menu "Paths and misc options"
|
|
|
|
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 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 TARBALLS_DIR
|
|
string
|
|
prompt "Tarballs directory"
|
|
default "${CT_TOP_DIR}/build/tarballs"
|
|
help
|
|
This is the directory into which tarballs are going to be stored once
|
|
they are downloaded (or otherwise retrieved).
|
|
|
|
config SRC_DIR
|
|
string
|
|
prompt "Extract directory"
|
|
default "${CT_TOP_DIR}/build/${CT_TARGET}/${CT_CC}-${CT_CC_VERSION}-${CT_LIBC}-${CT_LIBC_VERSION}/src"
|
|
help
|
|
This is the directory into which tarballs will be extracted.
|
|
|
|
If you will build multiple toolchains, you should arrange to have one
|
|
SRC_DIR for each toolchain, as different targets may require different
|
|
patches to be applied.
|
|
|
|
You should not need to change this from the default.
|
|
|
|
config BUILD_DIR
|
|
string
|
|
prompt "Build directory"
|
|
default "${CT_TOP_DIR}/build/${CT_TARGET}/${CT_CC}-${CT_CC_VERSION}-${CT_LIBC}-${CT_LIBC_VERSION}/build"
|
|
help
|
|
This is the directory into which builds will occur.
|
|
|
|
Once again, arrange for one build directory for each toolchain you build,
|
|
to avoid collision.
|
|
|
|
You should not need to change this from the default.
|
|
|
|
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.
|
|
|
|
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 "See warnings from the tool builds"
|
|
default n
|
|
depends on ! LOG_ERROR
|
|
help
|
|
If you say Y here, then you will have see the warning lines from
|
|
the components builds.
|
|
|
|
It should suffice to say N here, as those will anyway be visible
|
|
in the log file (if you want one).
|
|
|
|
config LOG_PROGRESS_BAR
|
|
bool
|
|
prompt "Progress bar"
|
|
default n
|
|
depends on ! LOG_ALL
|
|
help
|
|
This option will print a "rotating bar" (/-\|) below the last log line
|
|
to show work is not stalled.
|
|
|
|
Available when not in DEBUG log level.
|
|
|
|
config LOG_USE_COLORS
|
|
bool
|
|
prompt "Use colors for logging to console"
|
|
default n
|
|
help
|
|
Use colors to highlight important messages.
|
|
ERROR: bright red
|
|
WARN : bright yellow
|
|
INFO : bright green
|
|
EXTRA: dim green
|
|
DEBUG: dim white
|
|
|
|
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
|