Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
int
Rust
提交
7bf1de52
R
Rust
项目概览
int
/
Rust
大约 1 年 前同步成功
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
R
Rust
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
7bf1de52
编写于
4月 08, 2014
作者:
C
Corey Richardson
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
workcache: add crate doc block
上级
6ef2169b
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
66 addition
and
68 deletion
+66
-68
src/libworkcache/lib.rs
src/libworkcache/lib.rs
+66
-68
未找到文件。
src/libworkcache/lib.rs
浏览文件 @
7bf1de52
...
...
@@ -8,6 +8,72 @@
// option. This file may not be copied, modified, or distributed
// except according to those terms.
//! A simple function caching system.
//!
//! This is a loose clone of the [fbuild build system](https://github.com/felix-lang/fbuild),
//! made a touch more generic (not wired to special cases on files) and much
//! less metaprogram-y due to rust's comparative weakness there, relative to
//! python.
//!
//! It's based around _imperative builds_ that happen to have some function
//! calls cached. That is, it's _just_ a mechanism for describing cached
//! functions. This makes it much simpler and smaller than a "build system"
//! that produces an IR and evaluates it. The evaluation order is normal
//! function calls. Some of them just return really quickly.
//!
//! A cached function consumes and produces a set of _works_. A work has a
//! name, a kind (that determines how the value is to be checked for
//! freshness) and a value. Works must also be (de)serializable. Some
//! examples of works:
//!
//! kind name value
//! ------------------------
//! cfg os linux
//! file foo.c <sha1>
//! url foo.com <etag>
//!
//! Works are conceptually single units, but we store them most of the time
//! in maps of the form (type,name) => value. These are WorkMaps.
//!
//! A cached function divides the works it's interested in into inputs and
//! outputs, and subdivides those into declared (input) works and
//! discovered (input and output) works.
//!
//! A _declared_ input or is one that is given to the workcache before
//! any work actually happens, in the "prep" phase. Even when a function's
//! work-doing part (the "exec" phase) never gets called, it has declared
//! inputs, which can be checked for freshness (and potentially
//! used to determine that the function can be skipped).
//!
//! The workcache checks _all_ works for freshness, but uses the set of
//! discovered outputs from the _previous_ exec (which it will re-discover
//! and re-record each time the exec phase runs).
//!
//! Therefore the discovered works cached in the db might be a
//! mis-approximation of the current discoverable works, but this is ok for
//! the following reason: we assume that if an artifact A changed from
//! depending on B,C,D to depending on B,C,D,E, then A itself changed (as
//! part of the change-in-dependencies), so we will be ok.
//!
//! Each function has a single discriminated output work called its _result_.
//! This is only different from other works in that it is returned, by value,
//! from a call to the cacheable function; the other output works are used in
//! passing to invalidate dependencies elsewhere in the cache, but do not
//! otherwise escape from a function invocation. Most functions only have one
//! output work anyways.
//!
//! A database (the central store of a workcache) stores a mappings:
//!
//! (fn_name,{declared_input}) => ({discovered_input},
//! {discovered_output},result)
//!
//! (Note: fbuild, which workcache is based on, has the concept of a declared
//! output as separate from a discovered output. This distinction exists only
//! as an artifact of how fbuild works: via annotations on function types
//! and metaprogramming, with explicit dependency declaration as a fallback.
//! Workcache is more explicit about dependencies, and as such treats all
//! outputs the same, as discovered-during-the-last-run.)
#![crate_id
=
"workcache#0.11.0-pre"
]
#![crate_type
=
"rlib"
]
#![crate_type
=
"dylib"
]
...
...
@@ -33,74 +99,6 @@
use
std
::
io
;
use
std
::
io
::{
File
,
MemWriter
};
/**
*
* This is a loose clone of the [fbuild build system](https://github.com/felix-lang/fbuild),
* made a touch more generic (not wired to special cases on files) and much
* less metaprogram-y due to rust's comparative weakness there, relative to
* python.
*
* It's based around _imperative builds_ that happen to have some function
* calls cached. That is, it's _just_ a mechanism for describing cached
* functions. This makes it much simpler and smaller than a "build system"
* that produces an IR and evaluates it. The evaluation order is normal
* function calls. Some of them just return really quickly.
*
* A cached function consumes and produces a set of _works_. A work has a
* name, a kind (that determines how the value is to be checked for
* freshness) and a value. Works must also be (de)serializable. Some
* examples of works:
*
* kind name value
* ------------------------
* cfg os linux
* file foo.c <sha1>
* url foo.com <etag>
*
* Works are conceptually single units, but we store them most of the time
* in maps of the form (type,name) => value. These are WorkMaps.
*
* A cached function divides the works it's interested in into inputs and
* outputs, and subdivides those into declared (input) works and
* discovered (input and output) works.
*
* A _declared_ input or is one that is given to the workcache before
* any work actually happens, in the "prep" phase. Even when a function's
* work-doing part (the "exec" phase) never gets called, it has declared
* inputs, which can be checked for freshness (and potentially
* used to determine that the function can be skipped).
*
* The workcache checks _all_ works for freshness, but uses the set of
* discovered outputs from the _previous_ exec (which it will re-discover
* and re-record each time the exec phase runs).
*
* Therefore the discovered works cached in the db might be a
* mis-approximation of the current discoverable works, but this is ok for
* the following reason: we assume that if an artifact A changed from
* depending on B,C,D to depending on B,C,D,E, then A itself changed (as
* part of the change-in-dependencies), so we will be ok.
*
* Each function has a single discriminated output work called its _result_.
* This is only different from other works in that it is returned, by value,
* from a call to the cacheable function; the other output works are used in
* passing to invalidate dependencies elsewhere in the cache, but do not
* otherwise escape from a function invocation. Most functions only have one
* output work anyways.
*
* A database (the central store of a workcache) stores a mappings:
*
* (fn_name,{declared_input}) => ({discovered_input},
* {discovered_output},result)
*
* (Note: fbuild, which workcache is based on, has the concept of a declared
* output as separate from a discovered output. This distinction exists only
* as an artifact of how fbuild works: via annotations on function types
* and metaprogramming, with explicit dependency declaration as a fallback.
* Workcache is more explicit about dependencies, and as such treats all
* outputs the same, as discovered-during-the-last-run.)
*
*/
#[deriving(Clone,
Eq,
Encodable,
Decodable,
Ord,
TotalOrd,
TotalEq)]
struct
WorkKey
{
kind
:
StrBuf
,
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录