mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2024-12-20 13:23:08 +00:00
85622fdd49
This change adds support for experimental patches to be introduced to
crosstool-ng. The patches enabled by this option are to be located here:
patches/experimental/<package>/<version>/XXXX-NAME.patch
Where, XXXX is the patch number to be applied in order, like:
0001-some_patch_one.patch
0002-some_patch_two.patch
9999-some_patch_to_be_applied_last.patch
In the first patch series, all patches in the EXPERIMENTAL_PATCHES
option will be applied all at once, or none at all.
In a later [RFC] patch, I plan on adding finer tuned patch
enable/disable options based on the name of the patch and where it is
located in the patches/experimental sub-tree. So the name of the patch
should use underscores between words in the patch name.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: slightly reword prompt]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
151 lines
5.0 KiB
Plaintext
151 lines
5.0 KiB
Plaintext
# Options specific to crosstool-NG overall behavior
|
|
|
|
comment "crosstool-NG behavior"
|
|
|
|
config OBSOLETE
|
|
bool
|
|
prompt "Use obsolete features"
|
|
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... for which maintaining support in crosstool-NG
|
|
would be very costly.
|
|
|
|
It does not however mean that the specific feature or version has been
|
|
marked obsolete by the upstream team.
|
|
|
|
config EXPERIMENTAL
|
|
bool
|
|
prompt "Try features marked as EXPERIMENTAL"
|
|
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 me
|
|
the result
|
|
|
|
config EXPERIMENTAL_PATCHES
|
|
bool
|
|
depends on EXPERIMENTAL
|
|
prompt "Use patches marked as EXPERIMENTAL_PATCHES (READ HELP!)"
|
|
help
|
|
***WARNING*** This is not supported by crosstool-ng! ***WARNING***
|
|
|
|
If you set this to Y, then you will be able to enable experimental
|
|
patches that are not supported by crosstool-ng.
|
|
|
|
config ALLOW_BUILD_AS_ROOT
|
|
bool
|
|
prompt "Allow building as root user (READ HELP!)"
|
|
depends on EXPERIMENTAL
|
|
help
|
|
You normally do *not* need to be root to build a toolchain using
|
|
crosstool-NG. In fact, it is *VERY* dangerous to run as root, as
|
|
crosstool-NG will, as part of the build process, remove a few
|
|
directories. If anything goes wrong, running as root can ruin
|
|
your host distribution.
|
|
|
|
I can't stress it enough: DO NOT RUN AS ROOT !!
|
|
|
|
Do not run as root, you've been warned.
|
|
Do not come whining, if it nukes your host system.
|
|
Do not come whining, if you lose any data.
|
|
Do not run as root.
|
|
|
|
Do not run as root, you've been warned.
|
|
Do not come whining, if the Earth stops rotating.
|
|
Do not come whining, if kittens are smashed.
|
|
Do not run as root.
|
|
|
|
Do not run as root, do not run as root!
|
|
(ad libitum)
|
|
|
|
config ALLOW_BUILD_AS_ROOT_SURE
|
|
bool
|
|
prompt "Are you sure?"
|
|
depends on ALLOW_BUILD_AS_ROOT
|
|
|
|
config DEBUG_CT
|
|
bool
|
|
prompt "Debug crosstool-NG"
|
|
depends on ! BACKEND
|
|
help
|
|
Say 'y' here to get some options regarding debugging crosstool-NG.
|
|
|
|
if DEBUG_CT
|
|
|
|
config DEBUG_PAUSE_STEPS
|
|
bool
|
|
prompt "Pause between every steps"
|
|
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"
|
|
help
|
|
If you say 'y' here, then you will be able to restart crosstool-NG at
|
|
any step.
|
|
|
|
It is not currently possible to restart at any of the debug facilities.
|
|
They are treated as a whole.
|
|
|
|
To get the full list os steps, run: ct-ng list-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! :-) ).
|
|
|
|
config NO_OVERIDE_LC_MESSAGES
|
|
bool
|
|
prompt "Do *not* overide LC_MESSAGES (EXPERIMENTAL)"
|
|
depends on EXPERIMENTAL
|
|
help
|
|
By default, crosstool-NG sets and exports LC_ALL=C so that the
|
|
build.log file contains english messages, that can be read by
|
|
people most likely to help interpret the logs. If you say N here,
|
|
and your locale is not an english language, then dissecting your
|
|
log file will be difficult for most people but you.
|
|
|
|
If you say Y here, then your current locale settings will be used
|
|
to print messages, instead of plain english.
|
|
|
|
Say N, please.
|
|
|
|
config DEBUG_INTERACTIVE
|
|
bool
|
|
prompt "Interactive shell on failed commands"
|
|
help
|
|
If you say 'y' here, then an interactive shell will be spawned for
|
|
each failed command.
|
|
|
|
This shell will have the same environment that the failed command
|
|
was run with, and the working directory will be set to the directory
|
|
the failed command was run in.
|
|
|
|
After you fix the issue, you can exit the interactive shell with any
|
|
of these exit codes:
|
|
1 the issue was fixed, continue the build with the next command
|
|
2 the issue was fixed, re-run the failed command
|
|
3 abort the build
|
|
|
|
Note: '2' is only possible for commands run via CT_DoExecLog, though.
|
|
|
|
endif
|