Introduce a BROKEN option (depends on EXPERIMENTAL) to hide/see broken stuff for debugging sessions!
Re-order: OBSOLETE goes before EXPERIMENTAL.
1 # Overall toolchain configuration: paths, jobs, etc...
3 # Ah, this option is here to break the dependency tracking, and allow
4 # dependent option to line-up with the options they depend on ,rather
6 # Use it to intersperse two config options depending one on the other,
7 # but don't want the second to be indented (for example because you have
8 # a comment between the two to separate them). See DOWNLOAD and EXTRACT
9 # options to see how it is used.
14 menu "Paths and misc options"
16 comment "crosstool-NG behavior"
20 prompt "Use obsolete features"
23 If you set this to Y, you will be able to select obsolete features.
25 Such obsolete features are the use of old kernel headers, old
30 prompt "Try features marked as EXPERIMENTAL"
33 If you set this to Y, then you will be able to try very experimental
36 Experimental features can be one of:
37 - working, in which case you should tell me it is!
38 - buggy, in which case you could try patching and send me the result
39 - unfinished, in which case you could try hacking it and send me the result
40 - non-existant, in which case you could also try hacking it in and send the result
44 prompt "Try broken stuff"
46 depends on EXPERIMENTAL
48 Select this if you want to _debug_ broken stuff.
52 prompt "Debug crosstool-NG"
55 Say 'y' here to get some debugging options
59 config DEBUG_CT_PAUSE_STEPS
61 prompt "Pause between every steps"
64 Say 'y' if you intend to attend the build, and want to investigate
65 the result of each steps before running the next one.
67 config DEBUG_CT_SAVE_STEPS
69 prompt "Save intermediate steps"
72 If you say 'y' here, then you will be able to restart crosstool-NG at
75 It is not currently possible to rstart at any of the debug facility.
76 They are treated as a whole.
78 See docs/overview.txt for the list of steps.
80 config DEBUG_CT_SAVE_STEPS_GZIP
82 prompt "gzip saved states"
84 depends on DEBUG_CT_SAVE_STEPS
86 If you are tight on space, then you can ask to gzip the saved states
87 tarballs. On the other hand, this takes some longer time...
89 To lose as less time as possible, the gzip process is done with a low
90 compression ratio (-3), which gives roughly 70% gain in size. Going
91 further doesn't gain much, and takes far more time (believe me, I've
92 got figures here! :-) ).
96 comment "Build behavior"
100 prompt "Number of parallel jobs"
103 Number of jobs make will be allowed to run concurently.
104 Set this higher than the number of processors you have, but not too high.
105 A good rule of thumb is twice the number of processors you have.
107 Enter 1 (or 0) to have only one job at a time.
111 prompt "Maximum allowed load"
114 Specifies that no new jobs should be started if there are others jobs
115 running and the load average is at least this value.
117 Makes sense on SMP machines only.
119 Enter 0 to have no limit on the load average.
121 Note: only the integer part of the load is allowed here (you can't enter
130 Renices the build process up.
137 Use gcc's option -pipe to use pipes rather than temp files when building
142 config LOCAL_TARBALLS_DIR
144 prompt "Local tarballs directory"
147 If you have previously downloaded the tarballs, enter the PATH where
148 you stored them here.
152 prompt "Prefix directory"
153 default "${HOME}/${CT_TARGET}"
155 This is the path the toolchain will run from.
159 # prompt "Install directory"
160 default "${CT_PREFIX_DIR}"
162 # This is the path the target will be installed into.
164 # Normally, you would set this to ${CT_PREFIX_DIR}, but if for some reasons
165 # you can't write there, you can install somewhere else and have a third
166 # person do the install for you.
167 # The reason you might also want to install elsewhere is if you are going
168 # to package your shinny new toolchain for distribution.
172 prompt "Use custom patch directory"
175 If you have custom patches that you want to be applied, say 'Y' here and
176 enter the path directory below.
178 Note that you must ensure that the patch directory is arranged the same
179 way the official directory is.
181 config CUSTOM_PATCH_ONLY
183 prompt "Only use custom patches"
185 depends on CUSTOM_PATCH
187 Don't apply patches coming with crosstool-NG, only those patches available
188 in the directory below.
190 If you say 'N' here, then the patches provided with crosstool-NG will be
191 applied first, and then your patches.
193 config CUSTOM_PATCH_DIR
195 prompt "Custom patch directory"
197 depends on CUSTOM_PATCH
199 Enter the custom patch directory here.
203 prompt "Remove documentation"
206 Remove the installed documentation (man and info pages).
207 Gains around 8MiB for a uClibc-based, C and C++ compiler.
209 config INSTALL_DIR_RO
211 prompt "Render the toolchain read-only"
214 Render the directory of the toolchain (and its sub-directories)
217 Usefull for toolchains destined for production.
219 comment "Downloading"
221 config FORCE_DOWNLOAD
223 prompt "Force downloads"
226 Force downloading tarballs, even if one already exists.
228 Usefull if you suspect a tarball to be damaged.
232 prompt "Stop after downloading tarballs"
235 Only download the tarballs. Exit once it done.
237 Usefull to pre-retrieve the tarballs before going off-line.
247 prompt "Force extractions"
250 Force extraction of already exctracted tarballs.
252 Usefull if you suspect a previous extract did not complete (eg. broken
253 tarball), or you added a new set of patches for this component.
257 prompt "Stop after extracting tarballs"
260 Exit after unpacking and patching tarballs.
262 Usefull to look at the code before doing the build itself.
264 endif # ! ONLY_DOWNLOAD
270 prompt "Maximum log level to see:"
277 The build will be silent.
278 Only if there is an error will you see a message.
284 The same as above, plus warnings.
290 The same as above, plus informational messages (main steps).
296 The same as above, plus extra messages (sub-steps).
302 The same as above, plus lots of crosstool-NG debug information.
308 The same as above, plus all components build messages (very noisy!).
314 default "ERROR" if LOG_ERROR
315 default "WARN" if LOG_WARN
316 default "INFO" if LOG_INFO
317 default "EXTRA" if LOG_EXTRA
318 default "DEBUG" if LOG_DEBUG
319 default "ALL" if LOG_ALL
321 config LOG_SEE_TOOLS_WARN
323 prompt "Warnings from the tools' builds"
325 depends on ! LOG_ERROR
327 Treat warnings from the different tools as crosstool-NG warnings.
328 If you say 'y' here, then those warnings will be prefixed with
329 '[WARN ]' instead of the default '[ALL ]'.
331 You can safely say 'n' here. Those warnings will anyway be
332 recorded in the log file (provided you configured one).
334 Tools error will always be logged as crosstool-NG errors.
336 config LOG_PROGRESS_BAR
338 prompt "Progress bar"
342 If you say 'y' here, you'll be able to see the elapsed time.
344 As a bonus, you'll also get a rotating bar (/-\|) showing you
345 that the build is not stalled (the bar rotates 1/4 every 10 lines
346 of components build log).
348 Note that the elapsed time can stall for a little while if a
349 component has long commands, as the elapsed time is only updated
354 prompt "Log to a file"
357 Save *full* logs to a file. Even log levels you didn't specify above
358 will be available in this file. The log file will be named build.log
359 and stored in the toolchain prefix dir (set above).
361 As a bonus, there is a script in tools/extractConfig.sh that is able
362 to extract the configuration of crosstool-NG from the log file.
366 config LOG_FILE_COMPRESS
368 prompt "Compress the log file"
370 depends on LOG_TO_FILE
372 Compress the log file once the toolchain is successfully built.