LLAR 设计（稿2）

出发点

LLAR 虽然有反复造轮子的意味，但是LLAR设计出发点与conan，homebrew，xmake等工具是不同的。

Conan和Xmake都在关注C/C++生态编译，在这方面做了大量的工作，而Homebrew，APT等工具目标仅仅是为了提供能用的预构建包。虽然Conan尝试做预构建与编译方面的平衡，想要打造一款全能的构建工具，然而，Conan在这方面努力显然是不足的，因为他们管理不够完整，仅提供了部分的管理。这个问题出现的原因不言而喻--Conan其本身定位是构建工具，并非预构建下载。另一个Xmake，也有同样问题，虽然他们提供了Xrepo，但是Xrepo更多是Xmake扩展，而并非是Xmake关心的，他们更多也是关注在编译构建工具方面。

然而单独从编译构建工具来说，已经有太多太多成熟的工具了，GNU工具链，Ninja，Cmake.....我们没有必要再额外造一个编译构建工具。Conan的成功正是因为它不仅仅是一款构建工具，更重要的是，他为开发者提供了成熟的资产管理方案。

因此，LLAR出发点就是，我们想创造一款，既有完整资产管理方案（为预构建包提供在线编译管理需求），又可以提供便捷编译配置的包管理工具。换句话说，我们想追求的是二者的平衡。

产品设计

#9

模块划分

graph LR
	subgraph 0[" "]
		subgraph 1[​​应用层​​]
			1.1[LLAR Cli]
			1.2[LLAR 配方模块]
		end
		subgraph 2[​中间层​​]
			2.1[LLAR 用户 API]
			2.2[LLAR 数据管理 API]
		end
		subgraph 0.1["LLAR 后端"]
			subgraph 3[数据处理层]
				3.1[消息处理模块]
				3.2[(计算集群)]
				3.3[集群调度模块]
			end
			subgraph 4[数据管理层]
				4.1[云存储模块]
				4.2[配方产物管理模块]
				4.3[构建任务管理模块]
				4.4[(中心化配方管理仓库)]
			end
		end
	end

构建流程图

LLAR 采用 ​​"惰性编译"​​ 策略。这意味着当配方被合并时，系统并不会预先为所有可能的配置构建二进制包。相反，当用户请求一个二进制包时，LLAR Cli会通过 LLAR API查询 LLAR Backend。

如果请求的制品在后端已经存在，则会直接为用户下载。
如果未找到该制品，用户的请求会被提交给 LLAR Backend，以在云端触发一个新的构建任务。同时，为防止用户等待，系统会启动一个后备方案：在用户本地机器上也同时发起构建过程。

Cache Hit

sequenceDiagram
    participant U as User
    participant C as LLAR Cli
    participant A as LLAR API
    participant B as LLAR Backend

    U->>C: Request Binary
    C->>A: Query Artifact
    A->>B: Check Cache
    
    B-->>A: Artifact Found
    A-->>C: Download URL
    C->>B: Download Artifact
    B-->>C: Transfer Data
    C-->>U: Deliver Artifact

Cache Miss

sequenceDiagram
    participant U as User
    participant C as LLAR Cli
    participant A as LLAR API
    participant B as LLAR Backend
    participant S as Build System

    U->>C: Request Binary
    C->>A: Query Artifact
    A->>B: Check Cache
    
    B-->>A: Artifact Not Found
    A-->>C: Cache Miss Notification
        
    Note over U,S: Parallel Build Process
    B->>S: Trigger Cloud Build
    C->>U: Start Local Build
        
    S-->>B: Store Build Result

包设计

包是我们定义的一个抽象的概念，其实现载体为配方(Formula)。

一个包存在Package Name， Package ID，Desc（描述），Homepage（原库主页）

LLAR Package Name

格式：Owner/Repo

这个一般取自源库来源

我们举个例子，github.com/DaveGamble/cJSON

其LLAR Package Name应该为: DaveGamble/cJSON

如果是非Github托管的，看起来不存在此类格式，不过，我们依然可以取得这类名称，因为Package Name并无来源限制

举个例子：https://mumps-solver.org/MUMPS_1.2.tar.gz

维护者可以给他取 mumps-solver/MUMPS(暂不考虑）

Package Name很重要的一个用途就是将该package以人类可阅读的形式展示给用户，并不用于标识符使用

限制

Package Name唯一限制就是要求必须是ASCII中的可打印字符，不允许其他字符。

这个限制主要是因为，Package Name作为给用户展示的字符，不应该存在一些看起来乱码的字符

LLAR Package ID(暂不考虑）

我们之前曾经希望用Package Name作为标识符，cppkg曾这么做过。

然而Package Name作为标识符会导致很多问题：

1. 容易重名，我们不希望维护者因为重名问题浪费太多时间在想怎么取一个合适的名字
2. 检查重名需要额外逻辑

因此，我们还是需要给每一个Package生成一个完全独有的Package ID

于是，我们暂时选择了UUID-4作为Package ID生成

为什么选择UUID-4

高度随机，UUID-4冲突的概率非常非常小，这使得我们可以不需要关注重复的问题

这意味着，即使是后面引入第三方配方管理仓库，依然可以保证Package ID唯一性质。

生成时机

Package ID 的生成发生在 XGO Classfile 转换成 xgo_autogen.go 的过程中，具体逻辑如下：

1. 检查现有文件：在转换过程开始时，系统首先检查目标路径下是否已存在 xgo_autogen.go 文件

2. 读取已有 ID：

   • 如果 xgo_autogen.go 已存在，系统会解析该文件并提取其中已生成的 Package ID
   • 使用已有的 Package ID 可以确保同一个包在多次构建过程中保持标识符的一致性
   • 这对于版本管理和缓存机制至关重要

3. 生成新 ID：

   • 如果 xgo_autogen.go 不存在，系统会使用 UUID-4 算法自动生成一个新的 Package ID
   • 生成的 ID 会被自动插入到新创建的 xgo_autogen.go 文件中

flowchart TD
    A[XGO Classfile] --> B[转换过程开始]
    B --> C{检查 Package ID}
    C -->|不存在| D[生成 UUID-4]
    D --> E[插入 Package ID]
    E --> F[生成 xgo_autogen.go]
    C -->|已存在| F
    F --> G[完成]

配方设计

#13

配方存储方案设计

#16

Cli设计

#17

LLAR后端

#12

测试

脚本：

1. 利用go test对模块进行逐一测试，测试覆盖率85%

后端：

1. 利用go test对模块进行逐一测试，测试覆盖率85%

排期

任务	预期耗时	预期完成
建立中心化配方仓库和CI系统	2个星期	+14
编写FormulaApp基类	2个星期	+14
搭建后端环境	1个星期	+7
编写LLAR后端	1个月	+22
编写LLAR Cli	2个星期	+14

Start by reviewing the architecture, package, CLI, backend, and testing sections, along with the referenced issues #9, #13, #16, #17, and #12. The only concrete implementation detail named is UUID-4 handling during conversion to xgo_autogen.go; run the existing go test checks and clarify the intended first deliverable before coding.