| # Options related to paths and install |
| |
| comment "Paths" |
| |
| config LOCAL_TARBALLS_DIR |
| string |
| prompt "Local tarballs directory" if ! BACKEND |
| default "" |
| help |
| If you have previously downloaded the tarballs, enter the PATH where |
| you stored them here. |
| |
| config SAVE_TARBALLS |
| bool |
| prompt "Save new tarballs" if ! BACKEND |
| depends on LOCAL_TARBALLS_DIR != "" || BACKEND |
| default y if BACKEND |
| help |
| If you say 'y' here, new downloaded tarballs will be saved in the |
| directory you entered above. |
| |
| config WORK_DIR |
| string |
| prompt "Working directory" if ! BACKEND |
| default "${CT_TOP_DIR}/.build" |
| help |
| Set this to the directory where all build actions will be done. |
| |
| The default is "${CT_TOP_DIR}/.build", and leaving this option |
| empty will also use the default. |
| |
| You should not need to change that, except in one very peculiar |
| setup: |
| - your crosstool-NG source directory is on the network |
| - you configured crosstool-NG with --local |
| This kind of setup is a pain, as any action involving source file |
| access would have to go through the wire. In this case, you should |
| set CT_WORK_DIR to point to a path local to your machine, to avoid |
| any network overhead. |
| |
| Do *NOT* change it if you don't know better. |
| |
| config PREFIX_DIR |
| string |
| prompt "Prefix directory" if ! BACKEND |
| default "${HOME}/x-tools/${CT_TARGET}" |
| help |
| This is the path the toolchain will run from. |
| |
| config INSTALL_DIR |
| string |
| # prompt "Install directory" |
| default "${CT_PREFIX_DIR}" |
| # help |
| # This is the path the toolchain will be installed into. |
| # |
| # Normally, you would set this to ${CT_PREFIX_DIR}, but if for some reasons |
| # you can't write there, you can install somewhere else and have a third |
| # person do the install for you. |
| # The reason you might also want to install elsewhere is if you are going |
| # to package your shinny new toolchain for distribution. |
| |
| config RM_RF_PREFIX_DIR |
| bool |
| prompt "| Remove the prefix dir prior to building" |
| default y |
| depends on !BACKEND |
| help |
| If you say 'y' here, then PREFIX_DIR (above) will be eradicated |
| prior to the toolchain is built. |
| |
| This can be useful when you are trying different settings (due |
| to build failures or feature tests). In this case, to avoid using |
| a potentially broken previous toolchain, the install location is |
| removed, to start afresh. |
| |
| On the other hand, if you are building a final toolchain, and install |
| it into a directory with pre-install, unrelated programs, it would be |
| damageable to remove that directory. In this case, you may want to |
| say 'n' here. |
| |
| Note that when acting as a backend, this option is not available, and |
| is forced to 'n'. |
| |
| config REMOVE_DOCS |
| bool |
| prompt "Remove documentation" |
| default y |
| help |
| Remove the installed documentation (man and info pages). |
| Gains around 8MiB for a uClibc-based, C and C++ compiler. |
| |
| config INSTALL_DIR_RO |
| bool |
| prompt "Render the toolchain read-only" |
| default y |
| help |
| Render the directory of the toolchain (and its sub-directories) |
| read-only. |
| |
| Useful for toolchains destined for production. |
| |
| config STRIP_ALL_TOOLCHAIN_EXECUTABLES |
| bool |
| prompt "Strip all toolchain executables" |
| default y |
| help |
| All build host executables contain a lot of unnecessary info. |
| By stripping all executables it slightly speeds up the compilation |
| of large projects. |
| NOTE: It does NOT strip the target libraries, only HOST executables |
