config/global/paths.in
author "Antony N. Pavlov" <antony@niisi.msk.ru>
Sun Jul 17 16:53:40 2011 +0200 (2011-07-17)
changeset 2564 5d4e91c0343e
parent 2484 d1a8c2ae7946
child 2765 6c5658b8b588
permissions -rw-r--r--
misc: fix more typos here and there...

Reported-by: "Antony N. Pavlov" <antony@niisi.msk.ru>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
yann@445
     1
# Options related to paths and install
yann@1
     2
yann@1
     3
comment "Paths"
yann@1
     4
yann@85
     5
config LOCAL_TARBALLS_DIR
yann@1
     6
    string
yann@1865
     7
    prompt "Local tarballs directory" if ! BACKEND
yann@85
     8
    default ""
yann@1
     9
    help
yann@85
    10
      If you have previously downloaded the tarballs, enter the PATH where
yann@85
    11
      you stored them here.
yann@31
    12
yann@265
    13
config SAVE_TARBALLS
yann@265
    14
    bool
yann@1865
    15
    prompt "Save new tarballs" if ! BACKEND
yann@1865
    16
    depends on LOCAL_TARBALLS_DIR != "" || BACKEND
yann@1865
    17
    default y if BACKEND
yann@265
    18
    help
yann@425
    19
      If you say 'y' here, new downloaded tarballs will be saved in the
yann@265
    20
      directory you entered above.
yann@265
    21
yann@610
    22
config WORK_DIR
yann@610
    23
    string
yann@1865
    24
    prompt "Working directory" if ! BACKEND
yann@2109
    25
    default "${CT_TOP_DIR}/.build"
yann@610
    26
    help
yann@610
    27
      Set this to the directory where all build actions will be done.
yann@610
    28
      
yann@2419
    29
      The default is "${CT_TOP_DIR}/.build", and leaving this option
yann@610
    30
      empty will also use the default.
yann@610
    31
      
yann@610
    32
      You should not need to change that, except in one very peculiar
yann@610
    33
      setup:
yann@610
    34
       - your crosstool-NG source directory is on the network
yann@610
    35
       - you configured crosstool-NG with --local
yann@610
    36
      This kind of setup is a pain, as any action involving source file
yann@610
    37
      access would have to go through the wire. In this case, you should
yann@610
    38
      set CT_WORK_DIR to point to a path local to your machine, to avoid
yann@610
    39
      any network overhead.
yann@610
    40
      
yann@610
    41
      Do *NOT* change it if you don't know better.
yann@610
    42
yann@1
    43
config PREFIX_DIR
yann@1
    44
    string
yann@1865
    45
    prompt "Prefix directory" if ! BACKEND
yann@613
    46
    default "${HOME}/x-tools/${CT_TARGET}"
yann@1
    47
    help
yann@1
    48
      This is the path the toolchain will run from.
yann@1
    49
yann@1
    50
config INSTALL_DIR
yann@1
    51
    string
yann@1
    52
#    prompt "Install directory"
yann@1
    53
    default "${CT_PREFIX_DIR}"
yann@1
    54
#    help
yann@610
    55
#      This is the path the toolchain will be installed into.
yann@1
    56
#      
yann@1
    57
#      Normally, you would set this to ${CT_PREFIX_DIR}, but if for some reasons
yann@1
    58
#      you can't write there, you can install somewhere else and have a third
yann@1
    59
#      person do the install for you.
yann@1
    60
#      The reason you might also want to install elsewhere is if you are going
yann@1
    61
#      to package your shinny new toolchain for distribution.
yann@1
    62
yann@2284
    63
config RM_RF_PREFIX_DIR
yann@2284
    64
    bool
yann@2284
    65
    prompt "|  Remove the prefix dir prior to building"
yann@2284
    66
    default y
yann@2284
    67
    depends on !BACKEND
yann@2284
    68
    help
yann@2284
    69
      If you say 'y' here, then PREFIX_DIR (above) will be eradicated
yann@2284
    70
      prior to the toolchain is built.
yann@2284
    71
      
antony@2564
    72
      This can be useful when you are trying different settings (due
yann@2284
    73
      to build failures or feature tests). In this case, to avoid using
yann@2284
    74
      a potentially broken previous toolchain, the install location is
yann@2284
    75
      removed, to start afresh.
yann@2284
    76
      
antony@2564
    77
      On the other hand, if you are building a final toolchain, and install
yann@2284
    78
      it into a directory with pre-install, unrelated programs, it would be
yann@2284
    79
      damageable to remove that directory. In this case, you may want to
yann@2284
    80
      say 'n' here.
yann@2284
    81
      
yann@2284
    82
      Note that when acting as a backend, this option is not available, and
yann@2284
    83
      is forced to 'n'.
yann@2284
    84
yann@14
    85
config REMOVE_DOCS
yann@14
    86
    bool
yann@14
    87
    prompt "Remove documentation"
yann@753
    88
    default y
yann@14
    89
    help
yann@14
    90
      Remove the installed documentation (man and info pages).
yann@14
    91
      Gains around 8MiB for a uClibc-based, C and C++ compiler.
yann@14
    92
yann@174
    93
config INSTALL_DIR_RO
yann@174
    94
    bool
yann@174
    95
    prompt "Render the toolchain read-only"
yann@753
    96
    default y
yann@174
    97
    help
yann@174
    98
      Render the directory of the toolchain (and its sub-directories)
yann@174
    99
      read-only.
yann@174
   100
      
antony@2564
   101
      Useful for toolchains destined for production.
linux@2060
   102
linux@2060
   103
config STRIP_ALL_TOOLCHAIN_EXECUTABLES
linux@2060
   104
    bool
linux@2060
   105
    prompt "Strip all toolchain executables"
linux@2060
   106
    default y
linux@2060
   107
    help
linux@2060
   108
      All build host executables contain a lot of unnecessary info.
linux@2060
   109
      By stripping all executables it slightly speeds up the compilation
linux@2060
   110
      of large projects.
linux@2060
   111
      NOTE: It does NOT strip the target libraries, only HOST executables