Potentially add libclang as a build dependency
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 技术栈
- cpp
- 领域
- build-system
调研方向
该 issue 未指明任何文件、测试或入口点。首先评估所提议的基于 libclang 的 helper 及其对下游嵌入方的影响；只有在就兼容的构建依赖方案达成一致后，工作才算完成，但没有提供具体的验收标准。
由索引模型根据 Issue 内容生成。
描述
We (V8) are considering changing so of our codegen (in particular, instance type allocation) from being generated by Torque based on torque object definitions, into being generated by a libclang-based helper program that parses C++ object definitions -- the goal is to eventually remove the Torque object definitions entirely and have a single source of truth in C++. We likely don't need a bleeding-edge libclang since we're not going crazy with syntax here and libclang is relatively stable.
We're looking to make this part of the build rather than checking it in (like static roots) because the ifdef explosion is likely to be more severe. We want to make sure that downstream embedders are not entirely broken by this approach, and have some solution that's compatible with our plans. Please let me know if there are any insurmountable obstacles for you with an approach like this.
- 主要语言
- Jinja
- 星标
- 541
- 派生
- 185
- 平均合并
- 2 天 18 小时
- 30 天内合并 PR
- 6
贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
nodejs/build 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 70/100
-
platform:ppc
难度 1/5 1 小时以内 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 72/100
-
incident platform:arm
难度 4/5 3-5 天 新手友好度 35/100
-
难度 4/5 3-5 天 新手友好度 45/100
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 90/100
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
typelevel/sbt-typelevel#929 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
openSUSE/python-rpm-macros#219 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 1/5 1 小时以内 新手友好度 90/100
Qiskit/mcp-servers#221 ·