config/global/paths.in
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Tue Dec 13 23:32:39 2011 +0100 (2011-12-13)
branch1.13
changeset 2847 c0bf2319af08
parent 2484 d1a8c2ae7946
child 2765 6c5658b8b588
permissions -rw-r--r--
scripts: fix dumping execution backtrace

Dumping the backtrace has been broken since changeset #652e56d6d35a:
scripts: execute each steps in a subshell

We can spawn sub-sub-shells in some cases.

The way the fault handler works is to dump the backtrace, but to avoid
printing it once for every sub-shell (which could get quite confusing),
it simply exits when it detects that it is being run in a sub-shell,
leaving to the top-level shell the work to dump the backtrace.

Because each step is executed in its own sub-shell, the variable arrays
that contain the step name, the source file and line number, are lost
when exiting the per-step sub-shell.

Hence, the backtrace is currently limited to printing only the top-level
main procedure of the shell.

Fix this thus:
- when dumping the bckatraces for the steps & the functions, remember
it was dumped, and only dump it if it was not already dumped
- at the top-level shell, print the hints

Also, rename the top-level step label.

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