LLAR Cli设计

产品设计

背景

LLAR Cli是将LLAR与用户连接的"门户"(“Gateway”)，用户通过LLAR Cli与LLAR进行互动

需求

• 为用户提供统一的Cli接口用于LLAR管理
• 管理用户使用的配方脚本

用户故事

用户可以：

• 获取已经编译或者打包好的Package，以进行后续的编译操作
• 编译还没编译的Package，以进行后续的编译操作
• 获取编译好或者未编译好的Package版本信息，以了解目前有什么版本
• 获取编译好或者未编译好的Package构建信息，以了解目前有什么依赖
• 下载Package源码，但不进行编译
• 根据Package Name搜索Package
• 从多个重名Package中，提供具体信息让用户选择
• 执行配方，生成配方
• 添加第三方源（TODO）

具体设计

预缓存Package

llar download <PackageName>

关于<PackageName>定义可以看： #18

参数：
-s / --source: 仅获取源码不需要二进制包（默认仅获取二进制)
-a / --all: 不仅获取源码还获取二进制（同一个目录）
-json: 以JSON格式输出(默认无格式，仅方便人类阅读和编译器处理)

输出内容：包的构建信息，例如-lcjson

例子：

-lcjson -L/xxxx/cjson -I/xxxx/cjson/include

JSON格式：

{
	"LDFlags": "-L/xxxx/cjson -lcjson",
	"CFlags": "-I/xxxx/cjson/include"
}

内部流程图：

graph TD
A[用户] --> B{检查中心化仓库是否存在}
B -- 是 --> C{检查更新}
B -- 否 --> D[拉取中心化仓库]
C -- 有更新 --> E[更新仓库]
C -- 无更新 --> F[根据Package Name查找配方]
E --> F
D --> F
F --> G[执行配方]
G --> H[惰性构建]
H --> I[结束]

获取Package版本信息

llar list <PackageName>

-json: 以JSON格式输出(默认无格式，仅方便人类阅读和编译器处理)

输出内容：包的版本信息，例如-lcjson

例子：

1.7.18
1.7.17

JSON格式：

[{
	"Version": "1.7.18"
},
{
	"Version": "1.7.17"
}]

graph TD
A[用户] --> B{检查中心化仓库是否存在}
B -- 是 --> C{检查更新}
B -- 否 --> D[拉取中心化仓库]
C -- 有更新 --> E[更新仓库]
C -- 无更新 --> F[根据Package Name查找配方]
E --> F
D --> F
F --> G[执行配方]
G --> H[获取信息]
H --> I[结束]

获取Package构建信息

llar build info <PackageName>

参数：
-f / --filter, 正则过滤掉不需要的参数
-m / --match, 正则匹配需要的参数

如果二者组合使用，那么先过滤，后匹配

依赖管理

初始化Package

llar init <PackageName>

无输出

为当前Package添加依赖

llar get <PackageName>[@<PackageVersion>]

缺省：latest

例子: llar get madler/zlib@1.2.1

整理当前依赖

llar tidy

输出：TODO

搜索Package

用户可以通过Package Name来模糊搜索Package

llar search <Fuzzy PackageName>

-json: 以JSON格式输出(默认无格式，仅方便人类阅读和编译器处理)

输出：

Dave/cJSON:
	Desc: fast cJSON
	Homepage: xxxx

John/cjson:
	Desc: ultra fast cJSON, faster than above one
	Homepage: xxxx

JSON格式：

[{
	"PackageName": "Dave/cJSON",
	"Homepage": "xxxx"
},
{
	"PackageName": "John/cjson",
	"Homepage": "xxxx"
}]

配方仓库本地存储

The issue names no files, tests, or existing entry points. Start by locating the current CLI entry point and package-management implementation, then compare them with the specified download, list, build info, dependency, and search commands. Done would require an agreed implementation scope and behavior for these workflows, including the unresolved TODOs.