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.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 outBzero.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.includes. 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_envB0_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_dir.B0_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 action exec 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 exec, b0 tool exec and b0 action exec to resolve conflicts.B0_buildB0_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_metaB0_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.Exec.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.Exec. See how it goes fares for sync. Push/pull. In the optic of direct style I think we rather want ivars.
B0_storeIt'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_srcsb0.kit libraryB0_cIs missing.
B0_duneOn hold until we get the B0_srcs thing right.
B0_expect and testingLogging maybe move to:
B0_opamB0_release.release publish.B0_show_urlFor 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 test that run tests mark as such (or rather skips those unmarked).test/$(unit)/suite.ini b0 test -u test -t b0 bench -u bench -tB0.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)