mu/tools
Kartik K. Agaram 71e4f38129 7842 - new directory organization
Baremetal is now the default build target and therefore has its sources
at the top-level. Baremetal programs build using the phase-2 Mu toolchain
that requires a Linux kernel. This phase-2 codebase which used to be at
the top-level is now under the linux/ directory. Finally, the phase-2 toolchain,
while self-hosting, has a way to bootstrap from a C implementation, which
is now stored in linux/bootstrap. The bootstrap C implementation uses some
literate programming tools that are now in linux/bootstrap/tools.

So the whole thing has gotten inverted. Each directory should build one
artifact and include the main sources (along with standard library). Tools
used for building it are relegated to sub-directories, even though those
tools are often useful in their own right, and have had lots of interesting
programs written using them.

A couple of things have gotten dropped in this process:
  - I had old ways to run on just a Linux kernel, or with a Soso kernel.
    No more.
  - I had some old tooling for running a single test at the cursor. I haven't
    used that lately. Maybe I'll bring it back one day.

The reorg isn't done yet. Still to do:
  - redo documentation everywhere. All the README files, all other markdown,
    particularly vocabulary.md.
  - clean up how-to-run comments at the start of programs everywhere
  - rethink what to do with the html/ directory. Do we even want to keep
    supporting it?

In spite of these shortcomings, all the scripts at the top-level, linux/
and linux/bootstrap are working. The names of the scripts also feel reasonable.
This is a good milestone to take stock at.
2021-03-03 22:21:03 -08:00
..
termbox 7233 - fix some warnings from gcc 9 2020-11-13 20:53:32 -08:00
README.md 5868 2020-01-02 12:27:35 -08:00
browse_trace 5800 - move `browse_trace` to `tools/` dir 2019-12-07 18:15:49 -08:00
browse_trace.cc 5910 2020-01-20 02:58:31 -08:00
browse_trace.readme.md 5800 - move `browse_trace` to `tools/` dir 2019-12-07 18:15:49 -08:00
create_container 5891 2020-01-14 01:52:54 -08:00
expand_string_handle - 2020-05-18 00:44:50 -07:00
linkify.cc 5799 - move html-generation to `tools/` directory 2019-12-07 18:06:17 -08:00
stack_array.subx 6123 - runtime helper for initializing arrays 2020-03-11 17:21:59 -07:00
test_treeshake_translate 5796 - move treeshake to a new tools/ directory 2019-12-07 18:05:06 -08:00
treeshake.cc 5796 - move treeshake to a new tools/ directory 2019-12-07 18:05:06 -08:00
treeshake_all 6674 2020-07-25 15:35:43 -07:00
treeshake_translate 5899 2020-01-19 17:52:25 -08:00
update_html 7746 2021-02-14 16:48:02 -08:00
vga_palette 7842 - new directory organization 2021-03-03 22:21:03 -08:00
vga_palette.c 7842 - new directory organization 2021-03-03 22:21:03 -08:00
vga_palette.png 7842 - new directory organization 2021-03-03 22:21:03 -08:00

README.md

Run all these from the top-level mu/ directory.

Some tools for Mu's build process

These are built automatically.

  • enumerate: list numeric files in current directory, optionally --until some prefix.

Miscellaneous odds and ends

These are built lazily.

  • browse_trace: debugging tool. See browse_trace.readme.md for details.

  • linkify: inserts hyperlinks from variables to definitions in Mu's html sources. Hacky; just see the number of tests. Invoked by update_html.

  • treeshake_all: rebuild SubX binaries without tests and unused functions. Hacky; just helps estimate the code needed to perform various tasks.

    tools/treeshake_all
    

Notes to self: constraints on the tools/ directory

  • Don't overwhelm the initial view of the project with lots of crap in the root directory.
  • Directories go up top in the github view, so too many sub-directories are also overwhelming.
  • Don't increase increase build time too much; everything in tools/ shouldn't be automatically built.
    • stuff needed all the time is built from root directory.
  • tools/ contains many independent things; don't make it hard to see boundaries. Ideally just one source file per tool. If not, give related files similar name prefixes.