使用 JavaScript能使本网站更好的工作。
首页
探索
帮助
注册
登录
SisMaker
/
rebar3
关注
1
点赞
0
派生
0
代码
工单
0
合并请求
0
项目
0
版本发布
62
百科
动态
您最多选择25个主题
主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符
1435
提交
12
分支
11 MiB
目录树:
0fa0ff4f17
compile-type
hex_core
master
multi-pkg-dir
revert-1813-certifi-2.3.1
revert-2195-otp-23-master-compat-part2
revert-ebin_modules
rm-app_compilers-env
symlink_or_create_appsubdirs
v3.13
v3.13.1
xrl-yrl-recompile
3.14.3
3.14.2
3.14.1
3.14.0
3.14.0-rc2
3.14.0-rc1
3.13.2
3.13.1
3.13.0
3.12.0
3.11.1
3.11.0
3.10.0
3.9.1
3.9.0
3.8.0
3.7.5
3.7.4
3.7.3
3.7.2
3.7.1
3.7.0
3.7.0-rc2
3.7.0-rc1
3.6.2
3.6.1
3.6.0
3.5.3
3.5.2
3.5.1
3.5.0
3.4.7
3.4.6
3.4.5
3.4.4
3.4.3
3.4.2
3.4.1
3.4.0
3.3.6
3.3.5
3.3.4
3.3.3
3.3.2
3.3.1
3.3.0
3.2.0
3.1.1
3.1.0
3.0.0
3.0.0-beta.4
3.0.0-beta.3
beta-4
beta-2
beta-1
alpha-6
alpha-5
alpha-4
alpha-3
alpha-2
alpha-1
alpha
分支列表
标签列表
${ item.name }
创建分支
${ searchTerm }
从 '0fa0ff4f17'
${ noResults }
rebar3
/
inttest
/
tdeps3
/
a.erl
3 行
67 B
原始文件
普通视图
文件历史
Don't over-aggressively clean the code path in the presence of lib_dir directives Rebar, when it encounters a lib_dir directive, caches the current code path, adds the libdir(s) and returns the cached copy of the path. When rebar has finished processing that directory, it restores the cached path. This is problematic in the below scenario: /(lib_dir)->G A -> B -> C -> D -> E \-> F -> D -> E When rebar is finished processing B, it restores the code path to what it was before it processed B, removing C, D, E and G from the code path. This means when it comes to process F, neither D or E are in the code path, so any header includes, rebar plugins or parse transforms will not be in the code path. Without the lib_dir directive, rebar does no code path cleanups, so everything works fine. This change makes rebar only remove the explicit lib_dir code paths it added and adds an inttest that replicates the above scenario.
11 年前
-
module
(
{
{
module
}
}
)
.
-
include_lib
(
"
{{dep}}/include/{{dep}}.hrl
"
)
.