Design considerations and todo

Next

b0.std library

b0.memo library

b0.file library

Build fragments

At the b0 level we need to expose build fragments. It seems the build procedures of units is a good candidate but for now it's a bit unconvient to do that. We need to clarify the configuration store and dynamic metadata see B0_meta. For now as a temporary hack we add the wrap parameter to units.

B0_scope

* Is still quite dirty. Review.

B0_env

B0_unit

B0_unit.Action

B0_build

B0_meta

In the context of a merge with B0_store it should be possible to determine keys in various ways without needing to be explicit about it like for example the datatype of B0_unit.Action.env is. But If we build dynamics directly into keys, we should keep the option to keep keys static only.

It remains we want to built-in dynamic keys. Maybe explicit better as it allows to specify the dynamism scope on a key per key basis via the arguments of the function. We should however agree on a return type.

Dynamics. For now we used 'a Fut B0_meta.key or functional keys (see B0_unit.Action. See how it goes fares for sync. Push/pull. In the optic of direct style I think we rather want ivars.

B0_store

It's a bit unclear whether we don't want to merge B0_meta and B0_store perhaps at the expense of more complex B0_meta.Key.

Also for now only actions can mandate store bindings (e.g. to request a bytecode build). This should of course be user definable, likely at the build variant level.

B0_ocaml

B0_srcs

b0.kit library

B0_c

Is missing.

B0_dune

On hold until we get the B0_srcs thing right.

Testing and B0_testing and B0_expect

B0_opam

B0_release

B0_show_url

B0_jsoo

Got a bit stuck on trying to clean up the main units and getting rid of the show-uri bespoke action because .show-url.url has not future support and B0_jsoo.html_page relies on that, but then maybe it shouldn't. Unit ideas:

1. Unit exe (js only) 2. Unit html_page or bundle (more or less what current B0_jsoo.html_page. 3. Unit packed_html_page (packs all resource for single file distribution).

Tool

Deploy

For now let's see where the new actions bring us. But the idea is that a deploy is a way to selectively "save" the build.

Units should have a function that list what they want to save given a deploy env. This should just be a predicate, with keys possibly depending on build logics.

  b0 deploy web
  b0 deploy install
  b0 deploy -u unit install

Init

Documentation overhaul

Dump