v3-refactor: Implement v2 libs #1021
Conversation
| type: ghtagtar | ||
| repo: google/brotli | ||
| match: 'v1\.\d.*' | ||
| binary: hosted # 等价于v2的provide-pre-built: true |
There was a problem hiding this comment.
I don't think "binary" is the best description here. Binary could also refer to the binaries the artifact produces, not necessarily the prebuilt library.
There was a problem hiding this comment.
Pre-built library also belongs to a kind of binary I think. And hosted is just an alias like this:
"binary": {
"linux-x86_64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-aarch64-linux-musl-1.2.5.txz",
"extract": {
"bin/pkg-config": "{pkg_root_path}/bin/pkg-config"
}
},
"linux-aarch64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-x86_64-linux-musl-1.2.5.txz",
"extract": {
"bin/pkg-config": "{pkg_root_path}/bin/pkg-config"
}
},
"macos-x86_64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-x86_64-darwin.txz",
"extract": {
"bin/pkg-config": "{pkg_root_path}/bin/pkg-config"
}
},
"macos-aarch64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-aarch64-darwin.txz",
"extract": "{pkg_root_path}"
}
}My expected goal is:
That means that binary is a pre-built product that only needs to be installed, including the pre-built itself. If the hosted alias is expanded, it might look similar to the binary in pkg-config above.
There was a problem hiding this comment.
I get it, but going by conventions it's confusing. pre-built is better for this.
There was a problem hiding this comment.
It's true that pre-built is more appropriate than hosted. My main point before was to show that the pre-built version is built by our hosting actions. I will try to change this name later.
There was a problem hiding this comment.
I think hosted is fine, it's "binary" that's confusing here.
"pre-built": {
"linux-x86_64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-aarch64-linux-musl-1.2.5.txz",
"extract": {
"bin/pkg-config": "{pkg_root_path}/bin/pkg-config"
}
},
"linux-aarch64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-x86_64-linux-musl-1.2.5.txz",
"extract": {
"bin/pkg-config": "{pkg_root_path}/bin/pkg-config"
}
},
"macos-x86_64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-x86_64-darwin.txz",
"extract": {
"bin/pkg-config": "{pkg_root_path}/bin/pkg-config"
}
},
"macos-aarch64": {
"type": "ghrel",
"repo": "static-php/static-php-cli-hosted",
"match": "pkg-config-aarch64-darwin.txz",
"extract": "{pkg_root_path}"
}
}
This would be fine.
There was a problem hiding this comment.
My perspective is that since we've merged pre-built and pkg in v2 to artifact.binary in v3, or rather, the concept of v3 has been almost completely redefined, some of the original binary packages here are not part of the pre-built, or were not built by us. For example, nasm, go-xcaddy, etc.
I can't think of any other names besides binary that can represent "pre-built", "closed source software", and "other non-source artifacts" at the same time. Their functions and behaviors are the same.
There was a problem hiding this comment.
or were not built by us. For example, nasm, go-xcaddy, etc.
But they are nevertheless pre-built.
There was a problem hiding this comment.
But they are nevertheless pre-built.
I agree that closed-source software and third-party binaries are also "pre-built". But I prefer using the "what is it" instead of "how is it built" here.
V2 to V3 Migration Progress
Track the migration progress from v2 to v3 architecture. Using
yamlcould save a lot of redundant spaces and increase the readability.Libraries
Extensions
Build Target