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 "Save new tarballs"
154 depends on LOCAL_TARBALLS_DIR != ""
156 If you say 'y' here, new doanloaded tarballs will be saved in the
157 directory you entered above.
161 prompt "Prefix directory"
162 default "${HOME}/${CT_TARGET}"
164 This is the path the toolchain will run from.
168 # prompt "Install directory"
169 default "${CT_PREFIX_DIR}"
171 # This is the path the target will be installed into.
173 # Normally, you would set this to ${CT_PREFIX_DIR}, but if for some reasons
174 # you can't write there, you can install somewhere else and have a third
175 # person do the install for you.
176 # The reason you might also want to install elsewhere is if you are going
177 # to package your shinny new toolchain for distribution.
181 prompt "Use custom patch directory"
184 If you have custom patches that you want to be applied, say 'Y' here and
185 enter the path directory below.
187 Note that you must ensure that the patch directory is arranged the same
188 way the official directory is.
190 config CUSTOM_PATCH_ONLY
192 prompt "Only use custom patches"
194 depends on CUSTOM_PATCH
196 Don't apply patches coming with crosstool-NG, only those patches available
197 in the directory below.
199 If you say 'N' here, then the patches provided with crosstool-NG will be
200 applied first, and then your patches.
202 config CUSTOM_PATCH_DIR
204 prompt "Custom patch directory"
206 depends on CUSTOM_PATCH
208 Enter the custom patch directory here.
212 prompt "Remove documentation"
215 Remove the installed documentation (man and info pages).
216 Gains around 8MiB for a uClibc-based, C and C++ compiler.
218 config INSTALL_DIR_RO
220 prompt "Render the toolchain read-only"
223 Render the directory of the toolchain (and its sub-directories)
226 Usefull for toolchains destined for production.
228 comment "Downloading"
230 config FORCE_DOWNLOAD
232 prompt "Force downloads"
235 Force downloading tarballs, even if one already exists.
237 Usefull if you suspect a tarball to be damaged.
241 prompt "Stop after downloading tarballs"
244 Only download the tarballs. Exit once it done.
246 Usefull to pre-retrieve the tarballs before going off-line.
256 prompt "Force extractions"
259 Force extraction of already exctracted tarballs.
261 Usefull if you suspect a previous extract did not complete (eg. broken
262 tarball), or you added a new set of patches for this component.
266 prompt "Stop after extracting tarballs"
269 Exit after unpacking and patching tarballs.
271 Usefull to look at the code before doing the build itself.
273 endif # ! ONLY_DOWNLOAD
279 prompt "Maximum log level to see:"
280 default LOG_INFO if !DEBUG_CT
281 default LOG_DEBUG if DEBUG_CT
287 The build will be silent.
288 Only if there is an error will you see a message.
294 The same as above, plus warnings.
300 The same as above, plus informational messages (main steps).
306 The same as above, plus extra messages (sub-steps).
312 The same as above, plus lots of crosstool-NG debug information.
318 The same as above, plus all components build messages (very noisy!).
324 default "ERROR" if LOG_ERROR
325 default "WARN" if LOG_WARN
326 default "INFO" if LOG_INFO
327 default "EXTRA" if LOG_EXTRA
328 default "DEBUG" if LOG_DEBUG
329 default "ALL" if LOG_ALL
331 config LOG_SEE_TOOLS_WARN
333 prompt "Warnings from the tools' builds"
335 depends on ! LOG_ERROR
337 Treat warnings from the different tools as crosstool-NG warnings.
338 If you say 'y' here, then those warnings will be prefixed with
339 '[WARN ]' instead of the default '[ALL ]'.
341 You can safely say 'n' here. Those warnings will anyway be
342 recorded in the log file (provided you configured one).
344 Tools error will always be logged as crosstool-NG errors.
346 config LOG_PROGRESS_BAR
348 prompt "Progress bar"
352 If you say 'y' here, you'll be able to see the elapsed time.
354 As a bonus, you'll also get a rotating bar (/-\|) showing you
355 that the build is not stalled (the bar rotates 1/4 every 10 lines
356 of components build log).
358 Note that the elapsed time can stall for a little while if a
359 component has long commands, as the elapsed time is only updated
364 prompt "Log to a file"
367 Save *full* logs to a file. Even log levels you didn't specify above
368 will be available in this file. The log file will be named build.log
369 and stored in the toolchain prefix dir (set above).
371 As a bonus, there is a script in tools/extractConfig.sh that is able
372 to extract the configuration of crosstool-NG from the log file.
376 config LOG_FILE_COMPRESS
378 prompt "Compress the log file"
380 depends on LOG_TO_FILE
382 Compress the log file once the toolchain is successfully built.