| Commit message (Collapse) | Author | Age |
| |
|
|\
| |
| |
| | |
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current test wrapper works only when the inputs are specified using
relative paths. If they're specified with absolute paths, the driver
fails to detect the inputs because it always prepends the input dir name
which itself is a relative path:
$ cd tests
$ ./testwrapper.sh -d . -i $PWD/reject.txt -t ./reject_ver.table
<fails to open inputs>
This normally doesn't show up because people run `./configure` or, for
out of tree builds, `../configure`. But if you happen to run configure
with an absolute path, then automake tends to generate absolute paths
as well leading to test failures.
Fix all of this by dropping the implicit input directory prepending.
- INPUT_NAME is often a list of files, not just a single one
- the input directory is used to find the testname tables which are
usually generated, so it's impossible to use files from both source
and build directories
- most of the time, the full/correct path is already specified
|
| | |
|
| | |
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
flex v2.6.0 release
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
# gpg: Signature made Sat 05 Dec 2015 11:42:31 AM PST using RSA key ID 4F8BC9A4
# gpg: requesting key 4F8BC9A4 from hkp server pool.sks-keyservers.net
# gpg: no valid OpenPGP data found.
# gpg: Total number processed: 0
# gpg: keyserver communications error: key not found
# gpg: keyserver communications error: bad public key
# gpg: Can't check signature: public key not found
# Conflicts:
# Makefile.am
# NEWS
# autogen.sh
# configure.ac
# doc/Makefile.am
# doc/flex.texi
# examples/fastwc/mywc.c
# lib/Makefile.am
# lib/malloc.c
# lib/realloc.c
# po/POTFILES.in
# po/ca.po
# po/da.po
# po/de.po
# po/eo.po
# po/es.po
# po/fi.po
# po/fr.po
# po/ga.po
# po/hr.po
# po/ko.po
# po/nl.po
# po/pl.po
# po/pt_BR.po
# po/ro.po
# po/ru.po
# po/sr.po
# po/sv.po
# po/tr.po
# po/vi.po
# po/zh_CN.po
# po/zh_TW.po
# tests/Makefile.am
# tests/README
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
BUILT_SOURCES is now just the list of headers built as per the
automake manual. We provide the list of files to clean to make
rebuilding the test suite programs easier. We then use the CLEANFILES
list in a dist-hook to clean up the distribution that automake gathers
since not distributing flex generated files is foreign to automake's
mindset, but we need exactly that.
Additionally, we locate inputs to the tables-related tests more
precisely. Some files are in srcdir and some are in builddir, which
the arguments to the log compiler are now made aware of.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Added skel.c explicitly to MAINTAINERCLEANFILES in src/Makefile.am.
Added a bunch of files to built_SOURCES in tests/Makefile.am so that the
suite is easier to clean up.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
serialization and verification
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
The linedir_r test tested the implementation of line number tracking, not its results.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Also add -r option to testwrapper.sh to support passing input file as
a command line argument to the test scanner without using shell
redirection.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Split out reject test into its constituant tests. Add .reject tests
and .table tests for automake test log generation. Rewrite
testwrapper.sh to handle running with a tables file and specifying
optional input using command line options rather than positional
parameters.
|
| |
| |
| |
| |
| |
| | |
Also, remove the use of table files from this test as that tests two
features at once and we want to be as close to testing one feature at
a time as we can be.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|