NetBSD/regress
tnozaki 52ed7b035f Fixes PR lib/39662, shortcomings in LC_{MONETARY,NUMERIC,TIME,MESSAGES} db format.
ok'ed by core and releng.
(thanks for agc@, snj@ and i'm sorry for long time patience).

[libc]
- localeio.[ch] and lc*.[ch] in src/lib/libc/locale was replaced by
  new locale-db implementation using citrus_db backend,
  see src/lib/libc/citrus/citrus_lc_*.[ch].
- add citrus_bcs_strtou?l.c. don't use strtou?l locale implementation
  internally, because they're locale-aware function.
- add some stubs for multi-locale issue, see {current,global}_locale.c.
- remove some obsolete file, setrunelocale.c, ___runetype_mb.c.
- remove __savectype() from ctypeio.[ch].

[tools]
- mklocale(1): add new option ``-t'' that generates new style
  LC_{MONETARY,NUMERIC,TIME,MESSAGES} locale-db format.
- chrtbl(1): added ctypeio.[ch] for __savectype().

[locale-db]
- added en_US.US-ASCII locale.
- removed some shareable locale definition file:
    en_US.US-ASCII -> en_US.ISO8859-1, en_US.UTF-8
    zh_CN.eucCN -> zh_CN.GB18030
    and more...see src/share/locale/*/Makefile.
- remove obsoleted locale sr_YU, added new locale sr_ME, sr_RS.
- change locale name ja_JP.ISO2022-JP* -> ja_JP.ISO-2022-JP*
  for X11's locale.alias file alignments.
- fix regression test, wrong wcs?width(3), NAN/INF usage.

i tested release-build following arch:
  i386, amd64, hpc{mips,arm,sh}, sparc64, vax.

citrus_lc_*.[ch] also can read old-plain-text style locale-db.
so that backward compatibility is keeped, but lc*.[ch] can't read
new citrus_db'ed locale-db and localeio.c never check sanity,
so forward compatibility is broken ;-<

old mklocale(1) doesn't know -t option, so you have to rebuild toolchain.
2009-01-02 00:20:18 +00:00
..
bin trap in subshell 2008-12-21 03:15:53 +00:00
gnu also add -pthread to LDFLAGS; now this actually passes. 2008-02-09 08:38:08 +00:00
include Remove LKMs and switch to the module framework, pass 1. 2008-11-12 12:35:50 +00:00
lib Fixes PR lib/39662, shortcomings in LC_{MONETARY,NUMERIC,TIME,MESSAGES} db format. 2009-01-02 00:20:18 +00:00
libexec MKMAN should not be in source makefiles. Use NOMAN. 2008-03-09 22:44:41 +00:00
sys fix time_t formats 2008-12-29 05:56:02 +00:00
usr.bin Add AWK?=${TOOL_AWK} in regression tests for awk itself. 2008-10-27 20:59:22 +00:00
Makefile add regression tests for stuff recently fixed. 2008-12-21 00:24:06 +00:00
README Let me play regression test dictator for just one day: document rules that 2006-03-14 09:46:34 +00:00

README

$NetBSD: README,v 1.1 2006/03/14 09:46:34 martin Exp $

This part of the source tree contains regression tests. There are special
make targets and rules to follow. Most of these, however, are currently not
enforced, and most tests available are not conforming.

We hope to fix this someday. If you add new tests, please try to be conforming.

What is a regression test?

  A regression test is run by a makefile in a test directory (see below).
  Each makefile may run multiple tests.

What is a test directory?

  A directory in this part of the tree is a regression test directory. It
  contains a Makefile which implements the additional "regress" target,
  and runs all it's regression tests during this target.

May the make progress be stopped on failures?

  No, the "make regress" target should succeed, unless some regression 
  binaries could not be build, disk is full or other catastrophic failures
  outside of the tested subsystem happen. A failing regression test should
  log the failure (see below), but not make the target itself fail.

What are the possible results of a regression test?

  A test may either

  - succeed, in which case it logs "PASSED" (see below for logging details)
  - fail, in which case it logs "FAILED"
  - not be able to run, in which case it logs "SKIPPED" and the reason
    for the skip in the comment field (see below)

  Typical reasons for tests to not being run are missing kernel options,
  or missing privileges (test needs root, "make regress" is invoked by
  mere mortal or vice versa). A test may not fail because of such
  environmental issues, it must detect and properly log the problem.

  If a test directory contains tests that may be skipped, it should have
  a README file explaining the prerequisites (e.g. needed kernel options)

  In future, we will mark affected makefiles and optimize run/skipped test
  during repeated runs with differing privileges - but currently there is no
  make framework in place to handle this.

How and when does a test log results?

  If the make/environment variable ${REGRESS_LOG} is defined, the final
  results (and only those) should be logged to the file named by that
  variable. We will, in the future, add make targets for this purpose.
  The log format is line oriented, one line used per test. Each line
  consists of the directory where the Makefile lives, followed by the
  test name and the result (see above: PASSED, FAILED, SKIPPED).
  Following this an optional comment may be added. For SKIPPED tests the
  comment is not optional. Fields are separated by spaces.