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
10 menu "Paths and misc options"
12 comment "Crosstool-ng behavior"
16 prompt "Try features marked as EXPERIMENTAL"
19 If you set this to Y, then you will be able to try very experimental
22 Experimental features can be one of:
23 - working, in which case you should tell me it is!
24 - buggy, in which case you could try patching and send me the result
25 - unfinished, in which case you could try hacking it and send me the result
26 - non-existant, in which case you could also try hacking it in and send the result
30 prompt "Use obsolete features"
33 If you set this to Y, you will be able to select obsolete features.
35 Such obsolete features are the use of old kernel headers, old
40 prompt "Debug crosstool-NG"
43 Say 'y' here to get some debugging options
47 config DEBUG_CT_PAUSE_STEPS
49 prompt "Pause between every steps"
52 Say 'y' if you intend to attend the build, and want to investigate
53 the result of each steps before running the next one.
55 config DEBUG_CT_SAVE_STEPS
57 prompt "Save intermediate steps"
60 If you say 'y' here, then you will be able to restart crosstool-NG at
63 It is not currently possible to rstart at any of the debug facility.
64 They are treated as a whole.
66 See docs/overview.txt for the list of steps.
68 config DEBUG_CT_SAVE_STEPS_GZIP
70 prompt "gzip saved states"
72 depends on DEBUG_CT_SAVE_STEPS
74 If you are tight on space, then you can ask to gzip the saved states
75 tarballs. On the other hand, this takes some longer time...
77 To lose as less time as possible, the gzip process is done with a low
78 compression ratio (-3), which gives roughly 70% gain in size. Going
79 further doesn't gain much, and takes far more time (believe me, I've
80 got figures here! :-) ).
84 comment "Build behavior"
88 prompt "Number of parallel jobs"
91 Number of jobs make will be allowed to run concurently.
92 Set this higher than the number of processors you have, but not too high.
93 A good rule of thumb is twice the number of processors you have.
95 Enter 1 (or 0) to have only one job at a time.
99 prompt "Maximum allowed load"
102 Specifies that no new jobs should be started if there are others jobs
103 running and the load average is at least this value.
105 Makes sense on SMP machines only.
107 Enter 0 to have no limit on the load average.
109 Note: only the integer part of the load is allowed here (you can't enter
118 Renices the build process up.
125 Use gcc's option -pipe to use pipes rather than temp files when building
130 config LOCAL_TARBALLS_DIR
132 prompt "Local tarballs directory"
135 If you have previously downloaded the tarballs, enter the PATH where
136 you stored them here.
140 prompt "Prefix directory"
141 default "${HOME}/${CT_TARGET}"
143 This is the path the toolchain will run from.
147 # prompt "Install directory"
148 default "${CT_PREFIX_DIR}"
150 # This is the path the target will be installed into.
152 # Normally, you would set this to ${CT_PREFIX_DIR}, but if for some reasons
153 # you can't write there, you can install somewhere else and have a third
154 # person do the install for you.
155 # The reason you might also want to install elsewhere is if you are going
156 # to package your shinny new toolchain for distribution.
160 prompt "Use custom patch directory"
163 If you have custom patches that you want to be applied, say 'Y' here and
164 enter the path directory below.
166 Note that you must ensure that the patch directory is arranged the same
167 way the official directory is.
169 config CUSTOM_PATCH_ONLY
171 prompt "Only use custom patches"
173 depends on CUSTOM_PATCH
175 Don't apply patches coming with CT-NG, only those patches available in
178 If you say 'N' here, then the patches provided with CT-NG will be applied
179 first, and then your patches.
181 config CUSTOM_PATCH_DIR
183 prompt "Custom patch directory"
185 depends on CUSTOM_PATCH
187 Enter the custom patch directory here.
191 prompt "Remove documentation"
194 Remove the installed documentation (man and info pages).
195 Gains around 8MiB for a uClibc-based, C and C++ compiler.
197 config INSTALL_DIR_RO
199 prompt "Render the toolchain read-only"
202 Render the directory of the toolchain (and its sub-directories)
205 Usefull for toolchains destined for production.
207 comment "Downloading"
209 config FORCE_DOWNLOAD
211 prompt "Force downloads"
214 Force downloading tarballs, even if one already exists.
216 Usefull if you suspect a tarball to be damaged.
220 prompt "Stop after downloading tarballs"
223 Only download the tarballs. Exit once it done.
225 Usefull to pre-retrieve the tarballs before going off-line.
230 depends on ! ONLY_DOWNLOAD
234 prompt "Force extractions"
235 depends on ! ONLY_DOWNLOAD
238 Force extraction of already exctracted tarballs.
240 Usefull if you suspect a previous extract did not complete (eg. broken
241 tarball), or you added a new set of patches for this component.
245 prompt "Stop after extracting tarballs"
246 depends on ! ONLY_DOWNLOAD
249 Exit after unpacking and patching tarballs.
251 Usefull to look at the code before doing the build itself.
257 prompt "Maximum log level to see:"
264 The build will be silent.
265 Only if there is an error will you see a message.
271 The same as above, plus warnings.
277 The same as above, plus informational messages (main steps).
283 The same as above, plus extra messages (sub-steps).
289 The same as above, plus lots of crosstool-NG debug information.
295 The same as above, plus all components build messages (very noisy!).
301 default "ERROR" if LOG_ERROR
302 default "WARN" if LOG_WARN
303 default "INFO" if LOG_INFO
304 default "EXTRA" if LOG_EXTRA
305 default "DEBUG" if LOG_DEBUG
306 default "ALL" if LOG_ALL
308 config LOG_SEE_TOOLS_WARN
310 prompt "Warnings from the tools' builds"
312 depends on ! LOG_ERROR
314 Treat warnings from the different tools as crosstool-ng warnings.
315 If you say 'y' here, then those warnings will be prefixed with
316 '[WARN ]' instead of the default '[ALL ]'.
318 You can safely say 'n' here. Those warnings will anyway be
319 recorded in the log file (provided you configured one).
321 Tools error will always be logged as crosstool-ng errors.
323 config LOG_PROGRESS_BAR
325 prompt "Progress bar"
329 If you say 'y' here, you'll be able to see the elapsed time.
331 As a bonus, you'll also get a rotating bar (/-\|) showing you
332 that the build is not stalled (the bar rotates 1/4 every 10 lines
333 of components build log).
335 Note that the elapsed time can stall for a little while if a
336 component has long commands, as the elapsed time is only updated
341 prompt "Log to a file"
344 Save *full* logs to a file. Even log levels you didn't specify above
345 will be available in this file. The log file will be named build.log
346 and stored in the toolchain prefix dir (set above).
348 As a bonus, there is a script in tools/extractConfig.sh that is able
349 to extract the configuration of crosstool-NG from the log file.
353 config LOG_FILE_COMPRESS
355 prompt "Compress the log file"
357 depends on LOG_TO_FILE
359 Compress the log file once the toolchain is successfully built.