package MlFront_Exec

  1. Overview
  2. Docs
package MlFront_Exec
Legend:
Page
Library
Module
Module type
Parameter
Class
Class type
Source

Module MlFront_Exec.BuildTaskSource

Common functions used within build tasks and the build engine.

Sourcetype initiator =
  1. | UserInitiated of {
    1. agent : string;
    2. request_slot : MlFront_Thunk.ThunkCommand.object_slot option;
    }
    (*

    A user kicked off the build action (ex. building a target) themselves.

    agent is the name of the program or service which did the kicking off. Examples: agent = "mlfront-shell program".

    *)
  2. | CommandInitiated of {
    1. cid_command : string;
    2. cid_thunk_for_output : string;
    3. basedir : MlFront_Core.FilePath.t option;
    4. request_slot : MlFront_Thunk.ThunkCommand.object_slot option;
    }
    (*

    A command initiated the build action (ex. running a precommand).

    cid_command is the canonical id of the precommand.

    cid_thunk_for_output is the canonical id of the thunk that initiated the build (ex. not the precommand but the thunk that contains the precommand).

    basedir is the directory for which any relative paths of the precommand should be resolved. That is, if basedir = Some "a/b/c" and a precommand has "-f x/y/z" then the precommand should be resolved to "-f a/b/c/x/y/z". Typically basedir is the path to the thunk function's current working directory.

    *)
  3. | FunctionInitiated of {
    1. cid_thunk : string;
    2. request_slot : MlFront_Thunk.ThunkCommand.object_slot option;
    }
    (*

    A thunk function initiated the build action (ie. running the thunk function).

    cid is the canonical id of the thunk containing the function.

    *)

The initiator of a build action. TODO: Rename to request.

Sourceval initiator_slot_request_id : initiator -> MlFront_Thunk.ThunkCommand.object_slot option
Sourceval resolve_bundle_output_path : config:BuildConfig.t -> cid:string -> MlFront_Core.FilePath.t
Sourceval resolve_task_output_path : config:BuildConfig.t -> cid:string -> MlFront_Thunk.ThunkCommand.object_slot -> MlFront_Core.FilePath.t
Sourceval resolve_user_output_path : config:BuildConfig.t -> MlFront_Thunk.ThunkCommand.object_slot -> MlFront_Core.FilePath.t
Sourceval resolve_task_function_path : config:BuildConfig.t -> cid:string -> MlFront_Thunk.ThunkCommand.object_slot -> MlFront_Core.FilePath.t
Sourceval resolve_task_log_path : config:BuildConfig.t -> cid:string -> MlFront_Thunk.ThunkCommand.object_slot -> MlFront_Core.FilePath.t
Sourceval resolve_labeled_path : config:BuildConfig.t -> initiator:initiator -> [ `MoreIncludes | `Home | `Cache | `Data | `Config | `State | `Runtime | `PipeAsRegularFile of string | `StagedArchiveMember of string | `StagedConstant ] -> MlFront_Core.FilePath.t

resolve_labeled_path ~threaddir ~initiator label

Sourceval resolve_staging_path : config:BuildConfig.t -> initiator:initiator -> cid:string -> MlFront_Core.FilePath.t

resolve_staging_path ~config ~initiator ~cid gets the staging path from the configuration config for the build task initiator initiator and the canonical id cid of an AST, bundle or asset.

Staging paths are directories for intermediate (temporary) files.

Sourceval eval_term_as_filepath : ?platform:[ `Windows | `Unix ] -> config:BuildConfig.t -> initiator:initiator -> MlFront_Thunk.ThunkCommand.evalable_term -> (MlFront_Core.FilePath.t, string) result

eval_term_as_filepath ~config ~initiator term evaluates the term term into a file path.

The evaluation starts at the initiator's basedir which defaults to ".", then scans the term term from left to right, appending to the path as it goes. However, when a directory variable like "${HOME}" or "${SLOT.slotname}" is encountered, the evaluation ignoring any previously-encountered paths, jumps directly to that directory, and continues from there.

So "a/b/c/${HOME}/d/e" becomes "${HOME}/d/e", and "a/b/c/${SLOT.slotname}/d/e" becomes "${SLOT.slotname}/d/e".

And if relative_path = Some "x/y/z" then "a/b/c" becomes "x/y/z/a/b/c", and "${HOME}/d/e" becomes "${HOME}/d/e".

The initiator helps resolve directory paths like "${SLOT.slotname}".

The ~platform overrides how slashes are handled. If ~platform = `Windows then backslash is the directory separator. If ~platform = `Unix then forward slash is the directory separator. If ~platform is not provided, then the slashes are inferred from the slashes provided in the term. You should prefer not setting the ~platform parameter unless you intend to display both platforms to the end-user.

Sourceval eval_term_as_string : ?platform:[ `Windows | `Unix ] -> config:BuildConfig.t -> initiator:initiator -> MlFront_Thunk.ThunkCommand.evalable_term -> (string, string) result

eval_term_as_string ?platform ~config ~initiator term evaluates the term term into a string.

The evaluation scans the term term from left to right, appending to the string as it goes.

The initiator helps resolve directory paths like "${SLOT.slotname}".

The ~platform overrides how slashes are handled. If ~platform = `Windows then backslash is the directory separator. If ~platform = `Unix then forward slash is the directory separator. If ~platform is not provided, then the slashes are inferred from the slashes provided in the term. You should prefer not setting the ~platform parameter unless you intend to display both platforms to the end-user.

Sourceval value_id_form_object : cid:string -> build:string list -> MlFront_Thunk.ThunkCommand.object_slot -> string

value_id_form_object ~cid ~build slot is the value id for the value generated by an input form with canonical id cid with the semver build metadata build (ex. "bn-1234") for the slot slot.

In our reference implementation value store the value id is "o" :: hash(cid :: user_slot :: <future form parameters> :: build). But in your implementation you can use something else. The technical requirement is that your build clients can retrieve the immutable object from any of the build machines using that id. Confer BuildCore.Alacarte_3_2_apparatus.V.

Sourceval value_id_bundle : cid:string -> build:string list -> unit -> string

value_id_bundle ~cid ~build () is the value id for the value generated by an input bundle with canonical id cid with the semver build metadata build (ex. "bn-1234") for the slot slot.

In our reference implementation value store the value id is "b" :: hash(cid :: build). But in your implementation you can use something else. The technical requirement is that your build clients can retrieve the immutable object from any of the build machines using that id. Confer BuildCore.Alacarte_3_2_apparatus.V.

Sourceval value_id_asset : cid:string -> build:string list -> unit -> string

value_id_asset ~cid ~build () is the value id for the value generated by an input asset with canonical id cid with the semver build metadata build (ex. "bn-1234") for the slot slot.

In our reference implementation value store the value id is "a" :: hash(cid :: build). But in your implementation you can use something else. The technical requirement is that your build clients can retrieve the immutable object from any of the build machines using that id. Confer BuildCore.Alacarte_3_2_apparatus.V.

Sourcetype 'a ast_answer = {
  1. answer : 'a;
  2. answer_values_file : BuildCore.Io.file_object;
  3. answer_values_file_sha256 : string;
  4. answer_values_canonical_id : string;
}

depend_on_distribution_and_values_ast ~fetch ~error_locations ~values_file_sha256 f fetches the distribution package for the module module_version and the values file with SHA256 checksum values_file_sha256 using the dependency fetching function fetch, validates the module version module_version belongs to the distribution, parses the values file into an AST, and applies f to the AST.

The distribution package is calculated from the module_vesrion using SecDist.package_id_for_module.

If the values file cannot be fetched or parsed, a failure is emitted to the continuation using error_locations and the function returns `Failure_is_pending.

If the values file is successfully fetched and parsed, and if f ast is Some answer, then the function returns `FoundInValues { answer; ... }.

If the values file is successfully fetched and parsed, but if f ast is None, then an error is issued to the continuation using error_locations and the function returns `Failure_is_pending.

depend_on_distribution_and_values_ast ~fetch ~error_locations ~module_version ~values_file_sha256 f fetches the distribution package for the module module_version and the values file with SHA256 checksum values_file_sha256 using the dependency fetching function fetch, validates the module version module_version belongs to the distribution, parses the values file into an AST, and applies f to the AST.

The distribution package is calculated from the module_vesrion using SecDist.package_id_for_module.

If the values file cannot be fetched or parsed, a failure is emitted to the continuation using error_locations and the function returns `Failure_is_pending.

If the values file is successfully fetched and parsed, and if f ast is Some answer, then the function returns `FoundInValues { answer; ... }.

If the values file is successfully fetched and parsed, but if f ast is None, then an error is issued to the continuation using error_locations and the function returns `Failure_is_pending.

Sourceval package_is_local : BuildConfig.t -> MlFront_Core.PackageId.t -> bool

package_is_local config pkg returns true if the package pkg is local according to the configuration config, which allows the package to be built without needing an imported remote distribution.