Merge pull request #376 from jcburley/doc-circularities

Noting more about circularities in build process

DEVELOPER.md

@@ -227,7 +227,7 @@ Then, besides putting that source code in `core/data/*.joke`, one must:
 Further, if the new namespace depends on any standard-library-wrapping namespaces:
 
 * Edit the **core/gen\_common/gen\_common.go** `import` statement to include each such library's Go code
-* Ensure that code has already been generated (that library's `std/*/a_*.go` files have already been created), perhaps by using an older version of Joker to run `generate-std.joke` from within the `std` subdirectory
+* Ensure that code has already been generated (that library's `std/*/a_*.go` files have already been created), perhaps using an older version of Joker to run `generate-std.joke` from within the `std` subdirectory
 
 Create suitable tests, e.g. in `tests/eval/`.
 
@@ -414,6 +414,10 @@ arguments in `...`.
 
 ### Beware Circular Dependencies
 
+Joker currently has circular dependencies between the _core_ and _std_ namespaces, as well as within the _std_ namespace itself.
+
+#### Circular Dependencies Between Core and STD Namespaces
+
 There's actually a circular dependency between the two sets of namespaces:
 
 * `core/gen_common/gen_common.go` imports `std/string` (so `core/gen_data/gen_data.go` and `core/gen_code/gen_code.go` do as well), so the initialization code that adds the namespace is run
@@ -427,6 +431,24 @@ However, a `std/*.joke` file therefore cannot depend on any `core/data/*.joke`-d
 
 So, while `joker.repl` and `joker.tools.cli` currently depend on `joker.string`, `std/string.joke` does not depend on them, and preexisted their being added to the core namespaces.
 
+One approach to avoid this problem without (any longer) including generated artifacts (`a_*.go` files) in the repository, nor requiring an old version of Joker for bootstrapping, would be for the build process (in `run.sh`) to start by building a Joker executable that includes only `joker.core`.
+
+Then, that interim Joker executable could be used to run `std/generate-std.joke` to generate the `a_*.go` files in `std/`, after which a "complete" version of Joker would then be built.
+
+However, as explained below, that wouldn't solve the problem entirely, since `std/generate-std.joke` currently requires more than just `joker.core` to work.
+
+#### Circular Dependencies Within STD
+
+The `std/*/a_*.go` files are needed to build Joker, but are generated by `std/generate-std.joke`, which needs Joker to run.
+
+Further, `std/generate-std.joke` requires both `joker.os` and `joker.string`.
+
+Those dependencies mean that even if the Joker build process was changed to start by building a Joker executable supporting only `joker.core`, the resulting executable would be unable to run `std/generate-std.joke`.
+
+Again, the presence of `std/*/a_*.go` (at least for `joker.os` and `joker.string`) in the repository avoids this being a problem. (Another solution would be to use an older version of Joker to be used to run `std/generate-std.joke` and thus build a "fresh" one.)
+
+Converting `joker.os` and `joker.string` into _core_ libraries (so, the underlying support code would be in `package core`), and adding them to the list of libraries built into an "interim" Joker executable (as described above), is one approach to solving this issue.
+
 ## Faster Startup
 
 **run.sh** builds (via the `go generate ./...` step) an extra set of Go source files that, unless disabled via a build tag, statically initialize most of the core namespace info. (Some runtime initialization must still be performed, due mainly to limitations in the Go compiler.)