I’m refining the granularity of toolchain and build task support in OBazl. In particular, precise control over flags and options. There are three basic build tasks (compile, archive, and link executable); some options work for all three, and some are task-specific (e.g. ‘-open’ is for compiling). Furthermore different toolchains support different options.
Devs need the ability to group options into “profiles”. So if we want dev, dgb, test, and release profiles, across multiple toolchains, we risk detonating combinatorial explosions.
OBazl addresses this by supporting “toolchain profiles”. A toolchain profile has several attributes to aggregate task-specifc options: compile_options, archive_options, link_options. One profile can be used for many toolchains, or for toolchains fitting a description (e.g. targets the VM or some HW architecture, with debug enabled).
For testing, I could use a list of options by task. The compilers have a lot of options listed by --help that are not in the official documentation and for most of them, I have no idea which tasks they control. I suspect such a list would be useful in general. Anybody have such a thing?
Thanks,
Gregg
By the way, “native” and “bytecode” are not treated as “modes” by OBazl. They’re expressed as toolchains. So to emit bytecode you tell Bazel that the target host is VM, and it selects the appropriate toolchain.
The undocumented options of the compilers are all related to compiler-debugging: most of them control the printing of various internal intermediary representations. They are not really useful outside of compiler development.
Understood, but there are also lots of underdocumented options, like -unbox-closures and inline-max-unroll. In any case, I’m more interested in simple classification - these opts are compiling, these for linking, etc. - than full documentation.
WRT compiler development: toolchain profiles should be useful for compiler developers as well, I think. I’ve had a proof-of-concept build of the compiler using Bazel for months, it just needs to be updated and polished.
Thanks.
The -unbox-closures option is documented?
-unbox-closures Pass free variables via specialised arguments rather than closures
Moreover, searching the option in the manual leads to OCaml - Optimisation with Flambda which explains that this a flambda-only compilation option.