mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2025-01-31 16:36:14 +00:00
1c0488792d
When CT_PARALLEL_JOBS is -1, set the number of parallel jobs to the number of online CPUs + 1. Update documentation to match. I find this useful when building in the cloud. You can use the same .config file and have the build adapt to the number of processors available. Limited testing shows that NCPUS+1 is faster than NCPUS+0 or NCPUS+2. Signed-off-by: Michael Hope <michael.hope@linaro.org>
114 lines
3.4 KiB
Plaintext
114 lines
3.4 KiB
Plaintext
# Options related to how the build behaves
|
|
|
|
comment "Build behavior"
|
|
|
|
comment "Build options hiden"
|
|
depends on BACKEND
|
|
|
|
config PARALLEL_JOBS
|
|
int
|
|
prompt "Number of parallel jobs" if ! BACKEND
|
|
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.
|
|
|
|
Enter -1 to set automatically based on how many processors the host has.
|
|
|
|
config LOAD
|
|
int
|
|
prompt "Maximum allowed load" if ! BACKEND
|
|
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 USE_PIPES
|
|
bool
|
|
prompt "Use -pipe" if ! BACKEND
|
|
default y
|
|
help
|
|
Use gcc's option -pipe to use pipes rather than temp files when building
|
|
the toolchain.
|
|
|
|
choice
|
|
bool
|
|
prompt "Shell to use as CONFIG_SHELL"
|
|
default CONFIG_SHELL_BASH
|
|
depends on ! BACKEND
|
|
|
|
config CONFIG_SHELL_SH
|
|
bool
|
|
prompt "sh (the system shell)"
|
|
help
|
|
Use 'sh' as CONFIG_SHELL.
|
|
|
|
./configure scripts and Makefiles make intensive use of calling
|
|
sub-shells. This is usually done by calling /bin/sh. /bin/sh ought
|
|
to be an at-least-POSIX-conformant shell (that is, able to interpret
|
|
POSIX shell scripts).
|
|
|
|
On many (most?) systems, /bin/sh is a symlink to bash. On some other
|
|
systems (eg. Ubuntu, latest Debian), /bin/sh points to dash (or ash).
|
|
bash is a full-featured shell, with many extension to POSIX, but is
|
|
quite slow (see ection BUGS in the bash man page), while dash is
|
|
faster, with very few extensions to POSIX. On the other hand, some
|
|
./configure scripts, although written to use /bin/sh, may really
|
|
require to be run by bash.
|
|
|
|
The default is to use bash, as some components (eg. GMP) will fail
|
|
to build with anything else than bash.
|
|
|
|
config CONFIG_SHELL_ASH
|
|
bool
|
|
prompt "ash (READ HELP!)"
|
|
help
|
|
Use 'ash' as CONFIG_SHELL.
|
|
|
|
See help for CONFIG_SHELL_SH, above, for more explanations.
|
|
|
|
NOTE: It is advised that you do NOT use ash as CONFIG_SHELL, as some
|
|
components are broken. If you decide to use ash, and the build breaks,
|
|
don't come moaning and set the CONFIG_SHELL to bash, below.
|
|
|
|
config CONFIG_SHELL_BASH
|
|
bool
|
|
prompt "bash"
|
|
help
|
|
Use 'bash' as CONFIG_SHELL.
|
|
|
|
See help for CONFIG_SHELL_SH, above, for more explanations.
|
|
|
|
config CONFIG_SHELL_CUSTOM
|
|
bool
|
|
prompt "custom shell"
|
|
help
|
|
Enter full path to the custom shell below.
|
|
|
|
See help for CONFIG_SHELL_SH, above, for more explanations.
|
|
|
|
endchoice
|
|
|
|
config CONFIG_SHELL
|
|
string
|
|
default "sh" if CONFIG_SHELL_SH
|
|
default "ash" if CONFIG_SHELL_ASH
|
|
default "bash" if CONFIG_SHELL_BASH
|
|
default "custom" if CONFIG_SHELL_CUSTOM || BACKEND
|
|
|
|
config CONFIG_SHELL_CUSTOM_PATH
|
|
string
|
|
prompt "Path to custom shell" if ! BACKEND
|
|
depends on CONFIG_SHELL_CUSTOM || BACKEND
|
|
default "/bin/sh"
|