Skip to content

separate toolchain / platform tests from build tests #177

Open
@bdbaddog

Description

@bdbaddog

This issue was originally created at: 2002-03-25 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2002-03-25 22:00:00

From David Abrahams:

In general I hope that our build system /framework/ tests will not be dependent on doing much of anything with binary files. I would like to localize all of that in tests for individual toolsets and target platforms. Any individual tester probably doesn't have all the toolsets and platforms at his disposal; especially not within a single test run. It should be possible to pass "all" tests anyway. That's why I favor doing most of the testing with dummy toolset/platform specifications that operate portably in terms of simple text files.

Steven Knight:
We've been drifting towards this model. For example, our LEX and YACC tests use dummy Python scripts (again, created from in-line strings) as place-holders for the real lex and yacc utilities. The dummy scripts perform some simple processing on text-file input to mark that they've been executed.

However, we currently also look for a 'lex' or 'yacc' executable and run a test with "real" input if one exists. But we've already run into tool incompatibilities there, when we used the GNU-specific -o flag for lex and had to back off to the POSIX-standard -t option...

Your architectural separation of toolset / platform tests from build tool tests makes a lot of sense here. We should take a look at reorganizing the SCons tests along similar lines.

issues@scons said at 2002-03-25 22:00:00

Converted from SourceForge task item 50640

Metadata

Metadata

Assignees

No one assigned

    Labels

    testsuiteThings that only affect the SCons testing. Do not use just because a PR has tests.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions