git grep
XXX
, TODO
and FIXME
.b0.std
libraryB0_std.Os.Fd.copy
use sendfile
on Unix. On macOS we could use clonefile
(> 10.12) or copyfile
(> 10.5, uses clonefile if supported) – note though that this work on paths. See also copy_file_range.B0_std.String
. Perhaps a few combinators should be dropped and a few renamed, e.g. use `first` and `last` instead of `left` and `right`.b0.memo
libraryThe signature of B0_memo.write
looks wrong you want a fut. E.g. we don't want to the Fut.sync
here:
let crunch_file m file ~in_dir =
let open Fut.Syntax in
let mn = B0_ocaml.Mod.Name.of_mangled_filename (Fpath.basename file) in
let out = Fpath.(in_dir / String.Ascii.uncapitalize mn + ".ml") in
B0_memo.Memo.write m out ~reads:[file] begin fun () ->
(* FIXME b0 the sig of write is wrong *)
let data = Fut.sync (B0_memo.Memo.read m file) in
Ok (B0_memo_ocaml.Crunch.string_to_string ~id:"file" ~data)
end;
Fut.return out
Bzero.Op.post_exec
we may want to error. See for example B0_ocaml.script
.k
is a bit annoying to use. Synchronizing through writes could also be nice. We'd need an easy way to add a written file that is not written by the spawn but by the memo machinery.b0.file
libraryB0.ml
file finding. Should we stop at the last (vs the first now) B0.ml file upwards ? This would be nice if you operate in a vendored dir. But this also avoid problems like I do a checkout e.g. in a scratch directory in _b0
to build it. On the other hand we have --b0-file
for these cases.@@@B0.version
be added ? Think harder about it an especially with respect to B0_kit.V000
versioning. and coherence with @@@B0.include
s. Also we could require to specify say #require "b0.kit.v000"
. Write down a few properties we would like to have w.r.t. opam and/or inclusion and end-user support. Also if we use @@@B0.version
rather than open we might get in trouble with merlin. If would rather say no.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_build
into B0_env
. Rethink that when get back to redo build variants.Os
in B0_env
for actions. This might be needed for remote builds. In fact at some point we should indicate on which Os the action happens `Build
, `Host
or `Driver
(b0 invocation). Maybe it's then sufficient to a do proxy dance by executing the same b0 driver executable on the remote platform, at which point the Os
invocation run on the right platform. Do we ever want mixed `Build
and `Host
? Not undoable but a bit cold feet on replicating all the B0_std.Os
module in B0_env
to allow that.B0_build.B0_dir
.B0_unit
build_proc
to a meta key ? This would allow to name the build procedures like we do with actions.B0_unit.Action
.ocaml
ocaml
. Though you likely often only want to test an excutable or library so it's just a b0 -u myexec -- .ocaml ocaml
.ocaml
under .ocaml
but `.ocaml ocaml` will want a byte code build and `.ocaml ocamlnat` will want a native code build. So for now we have `.ocaml.ocaml`.b0 unit action
can be used for the action. If a tool conflicts with a unit warn if it's not the same unit. We should have all of b0 unit action
, b0 tool exec
to resolve conflicts.B0_build
B0_unit.tool_is_user_accessible
in builds. The B0_unit.in_root_scope
logic entails that build procedures may work when a build procedure may work when defined in a B0.ml
file and used as a root but no longer when it is included. Not good.B0_meta
B0_meta.Key
to B0_key
?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
.ocaml findmod MOD
, some stuff of `omod` could be integrated.B0_srcs
b0.kit
libraryB0_c
Is missing.
B0_dune
On hold until we get the B0_srcs
thing right.
B0_testing
and B0_expect
Logging maybe move to:
B0_opam
B0_release
.release publish
.B0_show_url
For now only tool names defined in units (as defined by b0 tool list
) can be used for the URL/tool execution form.
We likely want to be able to use it with actions aswell. But this needs a bit of twisting around since currently the action bit gets invoked at the end of the build. We need to be able to influence the build itself (especially since actions can influence the store) and for example the pack and units requires need to be able to be defined dynamically.
Basically the larger problems seems to be that currently it's difficult for actions to invoke actions.
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).
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
B0.ml
file style guide. Toplevel defs, constructor at the end except for actions. Doc strings either inline or first thing defining let
(lisp style).Profile stuff
xcrun xctrace record --template='Time Profiler' --launch -- \ $(b0 --path -- zipc unzip -t tmp/ebook.epub)