contrib/gcc-test-suite/README
author "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Thu Jul 28 22:09:31 2011 +0200 (2011-07-28)
changeset 2573 424fa2092ace
parent 1965 e3d532dd8b5d
child 2908 dcdb309b7967
permissions -rw-r--r--
scripts/libc: do not build add-ons by default

Currently, no --enable-add-ons option is passed to libc configure when
"$(do_libc_add_ons_list ,)" is empty, which makes configure automatically search
for present add-ons. In that case, all present add-ons are built, although
no add-on was selected by the user in the config. Moreover, this can make the
configure fail if some non-standard add-ons like eglibc-localedef are present.

This behavior also leads to an inconsistency from a user point of view between
the following cases:
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS="none" in the config,
which makes "$(do_libc_add_ons_list ,)" return "", so all present add-ons
are built.
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS!="none" in the
config, which makes "$(do_libc_add_ons_list ,)" return the add-on supporting
the chosen threading implementation, e.g. "nptl", so only this add-on is
built.

This patch disables the building of all add-ons in that case.

It is still possible to build all present add-ons by adding --enable-add-ons to
LIBC_GLIBC_EXTRA_CONFIG_ARRAY.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
mgl@1965
     1
mgl@1965
     2
Helper Makefile for testing gcc toolchains using the gcc-testsuite
mgl@1965
     3
==================================================================
mgl@1965
     4
mgl@1965
     5
Requirements
mgl@1965
     6
------------
mgl@1965
     7
mgl@1965
     8
* DejaGnu 'runtest' v1.4.4+
mgl@1965
     9
* Make v3.81+
mgl@1965
    10
mgl@1965
    11
mgl@1965
    12
Configuration
mgl@1965
    13
-------------
mgl@1965
    14
mgl@1965
    15
Edit default.cfg to reflect your toolchain and target configuration.
mgl@1965
    16
mgl@1965
    17
Alternatively, override configuration variables on the command line.
mgl@1965
    18
mgl@1965
    19
Available config variables:
mgl@1965
    20
mgl@1965
    21
DG_TOOLNAME
yann@1966
    22
  The name of the tool you want to test.
yann@1966
    23
  Currently supported: gcc or g++
yann@1966
    24
  Default: gcc
yann@1966
    25
mgl@1965
    26
DG_TARGET_HOSTNAME
yann@1966
    27
  The hostname or IP of the machine to execute run-tests
yann@1966
    28
  Default: 127.0.0.1
yann@1966
    29
mgl@1965
    30
DG_TARGET_USERNAME
yann@1966
    31
  Execute the run-test as this user on DG_TARGET_HOSTNAME
yann@1966
    32
  Default: root
yann@1966
    33
mgl@1965
    34
DG_C_TESTS
mgl@1965
    35
DG_CPP_TESTS
yann@1966
    36
  The C/C++ tests you want to check
yann@1966
    37
  Default: (empty, means all tests)
mgl@1965
    38
mgl@1965
    39
mgl@1965
    40
Run examples
mgl@1965
    41
------------
mgl@1965
    42
mgl@1965
    43
The first two examples require a networked target with ssh access and automatic
mgl@1965
    44
ssh login (see section below). Target SW should be compiled with the toolchain 
mgl@1965
    45
to be tested.
mgl@1965
    46
mgl@1965
    47
Run default gcc compile/execution tests:
mgl@1965
    48
$ make DG_TOOLNAME=gcc DG_TARGET_HOSTNAME=192.168.17.93 DG_TARGET_USERNAME=root
mgl@1965
    49
mgl@1965
    50
Run default g++ compile/execution tests:
mgl@1965
    51
$ make DG_TOOLNAME=g++ DG_TARGET_HOSTNAME=192.168.17.93 DG_TARGET_USERNAME=root
mgl@1965
    52
mgl@1965
    53
Run selected gcc compile only tests (no target required):
mgl@1965
    54
$ make DG_TOOLNAME=gcc DG_C_TESTS="compile.exp noncompile.exp" 
mgl@1965
    55
mgl@1965
    56
mgl@1965
    57
SSH automatic login configuration example
mgl@1965
    58
-----------------------------------------
mgl@1965
    59
mgl@1965
    60
On host do: 
mgl@1965
    61
ssh-keygen -t rsa (then simply press enter thru all steps)
yann@1966
    62
ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<target IP>
mgl@1965
    63
mgl@1965
    64
Now automatic ssh login should work - test by doing a simple ssh session to target.
mgl@1965
    65
mgl@1965
    66
Note: The procedure might be slightly different for your particular target.
mgl@1965
    67
mgl@1965
    68
yann@1966
    69
Getting rid of the test-suite
yann@1966
    70
-----------------------------
yann@1966
    71
yann@1966
    72
If you no longer have a need for the test-suite, then you can remove it altogether
yann@1966
    73
from your toolchain. Just delete the test-suite/ dub-dir.
yann@1966
    74
yann@1966
    75
mgl@1965
    76
Author
mgl@1965
    77
------
mgl@1965
    78
Martin Lund <mgl@doredevelopment.dk>
yann@1966
    79
  Initial content
yann@1966
    80
yann@1966
    81
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
yann@1966
    82
  Getting rid of the test-suite
yann@1966
    83
  Minor fixes