Add more TODOs requested by pull request reviewers
- Remove dependency on argp and gcc
- Report dev.dirs hanging problem
- Improve TDML Runner (actually my idea)
diff --git a/site/dev/design-notes/runtime2-todos.adoc b/site/dev/design-notes/runtime2-todos.adoc
index 37ae11e..5d4ae7a 100644
--- a/site/dev/design-notes/runtime2-todos.adoc
+++ b/site/dev/design-notes/runtime2-todos.adoc
@@ -36,6 +36,36 @@
please let the mailto:dev@daffodil.apache.org[dev] list know
in order to avoid duplication.
+=== Remove dependence on argp and gcc
+
+Update BUILD.md and the github actions to use clang instead of gcc.
+Will have to find the correct steps on Fedora / Linux / Windows
+and check they work (e.g., install clang-10 package on Ubuntu
+and set CC=clang-10 and AR=llvm-ar-10 environment variables).
+
+Likewise, replace argp calls with getopt calls
+in daffodil_main.c and daffodil_argp.c
+even though it means giving up long options
+and other nice features that argp has.
+
+=== Report hanging problem running sbt (really dev.dirs) from MSYS2 on Windows
+
+We need to open a issue with a reproducible test case
+in the dev.dirs/directories-jvm project on GitHub.
+Note that dev.dirs exhibits the problem
+but they may or may not be responsible for it.
+Their code which tries to run a Windows PowerShell script
+using a Java subprocess call hangs
+when run from MSYS2 on Windows
+although it works fine when run from CMD on Windows.
+Then we need to wait until
+the hanging problem is fixed in the directories library,
+coursier picks up the new directories version,
+sbt picks up the new coursier version,
+and daffodil picks up the new sbt version,
+before we can remove the "echo >> $GITHUB_ENV" lines
+from .github/workflows/main.yml.
+
=== Reporting errors using structs, not strings
We have replaced error message strings
@@ -99,35 +129,60 @@
=== Javadoc-like tool for C code
-We should consider adopting
-one of the javadoc-like tools for C code
+We should consider adopting one of the javadoc-like tools for C code
and structuring our comments that way.
=== DSOM "fixed" getter
Note: If we change runtime1 to validate "fixed" values
-like runtime2 does, then we can resolve {% jira 117 %}.
+like runtime2 does, then we can resolve
+https://issues.apache.org/jira/browse/DAFFODIL-117[DAFFODIL-117].
-=== Update to TDML Runner
+=== Improve TDML Runner
-We want to update the TDML Runner
+We want to improve the TDML Runner
to make it easier to run TDML tests
with both runtime1 and runtime2.
We want to eliminate the need
to configure a `daf:tdmlImplementation` tunable
in the TDML test using 12 lines of code.
-The TDML Runner should configure itself
-to run both/either runtime1 and/or runtime2
-just from seeing a root attribute
-saying `defaultImplementations="daffodil runtime2"`
-or a parser/unparseTestCase attribute saying `implementations="runtime2"`.
-Maybe we also want to add an implementation attribute
+
+I had an initial idea which was that
+the TDML Runner could run both runtime1 and runtime2
+automatically (in parallel or serially)
+if it sees a TDML root attribute
+saying `defaultImplementations="daffodil daffodil-runtime2"`
+or a parser/unparseTestCase attribute
+saying `implementations="daffodil daffodil-runtime2"`.
+To make running the same test on runtime1/runtime2 easier
+we also could add an implementation attribute
to tdml:errors/warnings elements
-saying which implementation they are for too.
-If we do that,
-we should tell the TDML Runner
-runtime2 tests are not cross tests
-so it will check their errors/warnings.
+saying which implementation they are for
+and tell the TDML Runner to check errors/warnings
+for runtime2 as well as runtime1.
+
+Then I had another idea which might be easier to implement.
+If we could find a way to set Daffodil's tdmlImplementation tunable
+using a command line option or environment variable
+or some other way to change TDML Runner's behavior
+when running both "sbt test" and "daffodil test"
+then we could simply run "sbt test" or "daffodil test" twice
+(first using runtime1 and then using runtime2)
+in order to verify all the cross tests work on both.
+I think this way would be easier than making TDML Runner
+automatically run all the implementations it can find
+in parallel or serially when running cross tests.
+
+If the second idea works as I hope it does,
+then we can start the process of adding "daffodil-runtime2"
+to some of the cross tests we have for daffodil and ibm.
+We also chould change ibm's ProcessFactory class
+to have a different name than daffodil's ProcessFactory class
+and update TDML Runner's match expression to use the new class name.
+Then some developers could add the ibmDFDLCrossTester plugin
+to their daffodil checkout permanently
+instead of having to do & undo that change
+each time they want to run daffodil/ibm cross tests.
=== C struct/field name collisions
