Add more thoughts to testcript note

1 files changed, 30 insertions, 8 deletions

diff --git a/build2/test/testscript b/build2/test/testscript
index c2e2365..d7a70f6 100644
--- a/build2/test/testscript
+++ b/build2/test/testscript
@@ -3,10 +3,10 @@
 Requirements
 ============
 
-* Multiple testscript files (to group related test)
-
 * Run multiple tests
 
+* Multiple testscript files (to group related test)
+
 * Specify exit status (optional, expect 0 by default).
 
 * Run pre/post test actions (setups/teardowns, e.g., database schema creation).
@@ -19,18 +19,18 @@ Requirements
 
 * Test description
 
-* Create (and automatically clean up) input files
+* Create (and automatically clean up) input/output files
 
 ? Variable expansion, looked up on target in buildfile
 
 * Ability to pass arguments from build files (how for multiple scripts?)
-  Could use $0, $1, $* if have variable expansion.
+  Could use $0, $1, $*.
 
 Questions
 =========
 
-* What is the testcript attached at the buildfile level? An executable? What
-  if the test is not for executable. I guess we always have the directory
+* What if the testcript attached at the buildfile level? An executable? What
+  if the test is not for an executable. I guess we always have the directory
   target.
 
   We could reuse the test variable to specify (list of) scripts:
@@ -38,7 +38,8 @@ Questions
   exe{hello}: test = test1 test2
 
 * Do we want a notion of multi-command test (e.g., with pre/post commands)?
-  Maybe {}? Will need it not to clean up output files too early.
+  Maybe {}? Will need it not to clean up output files too early. Also var
+  scope.
 
 Notes
 =====
@@ -74,7 +75,28 @@ EOO
 13 characters written
 EOE
 
-~ Built in cat command with auto-cleanup? To create files for tests, etc.
+~ Built-in cat command with auto-cleanup? To create files for tests, etc.
+
+~ Built-in sed(-like) utility? Note that GCC 4.8 has broken <regex> support,
+  only usable from 4.9. Could be a problem.
+
+~ We should probably allow assignment of variables and since we will also
+  lookup those defined in the buildfile, makes sense to use the same semantics
+  (and perhaps even the parser, like we do for command line). Also value
+  types.
+
+  So in a sense for each test we will have an "inner" variable scope where
+  we lookup first.
+
+~ Could support assigning output of a program to a variable:
+
+  foo = `sed ...`
+
+  The semantics should probably be "as if you had the output literally",
+  without any of the extra shell splitting nonsense, just the standard
+  buildfile logic.
+
+  Probably also support piping.
 
 ~ Output file redirects should be relative to out_base. Input? Could actually
   track created out files and use that if exists, and src otherwise. What if