Georgi Gerganov
805984d676
* ci : parallelize platform builds in build-xcframework.sh The ios-xcode release job builds 7 platform/simulator configurations sequentially, each with -j $(nproc). Run them with at most 3 concurrent builds (the release runner has 3 cores), splitting the cores between the builds (-j 1 each on the runner), so total CPU pressure is unchanged while the build phase runs about 2.3x faster. - convert the 7 build blocks into functions (flags unchanged) - add a run_builds_parallel pool: 3-slot sliding window, per-build logs, dumps the failing log and aborts on error (background job failures do not trigger set -e) - queue the 2-arch builds first so the slower builds occupy the slots early Assisted-by: pi:llama.cpp/Qwen3.8-27B * pi : add guideline for comments * cont : disable 5/7 builds * ci : make build-xcframework.sh builds configurable via CLI args The script now takes an optional list of builds to run (ios-sim ios-device macos visionos visionos-sim tvos-sim tvos-device); with no arguments it builds all of them, as before. The per-build lists for the build pool, framework setup, static library combining and xcframework creation are now driven by a single build_spec lookup instead of four hardcoded (partially commented-out) lists. release.yml builds only macos and ios-device to cut the build time. Assisted-by: pi:llama.cpp/Qwen3.8-27B
29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
You are a coding agent. Here are some very important rules that you must follow:
|
|
|
|
General:
|
|
- Be very precise and concise when writing code, comments, explanations, etc.
|
|
- If an inline comment exceeds 2 lines, replace it with: `// note: TODO LATER`
|
|
- PR and commit titles format: `<module> : <title>`. Lookup recents for examples
|
|
- Don't try to build or run the code unless you are explicitly asked to do so
|
|
- Use the `gh` CLI tool when querying PRs, issues, or other GitHub resources
|
|
|
|
Coding:
|
|
- When in doubt, always refer to the CONTRIBUTING.md file of the project
|
|
- When referencing issues or PRs in comments, use the format:
|
|
- C/C++ code: `// ref: <url>`
|
|
- Other (CMake, etc.): `# ref: <url>`
|
|
|
|
Pull requests (PRs):
|
|
- New branch names are prefixed with "gg/"
|
|
- Before opening a pull request, ask the user to confirm the description
|
|
- When creating a pull request, look for the repository's PR template and follow it
|
|
- For the AI usage disclosure section, write "YES. pi:llama.cpp/[MODEL]"
|
|
- Ask the user to tell you what model was used and write it in place of [MODEL]
|
|
- Always create the pull requests in draft mode
|
|
|
|
Commits:
|
|
- On every commit that you make, include a "Assisted-by: pi:llama.cpp/[MODEL]" tag
|
|
- Do not explicitly set the git author in commits - rely on the default git config
|
|
- Always use `--no-gpg-sign` when committing
|
|
- Never `git push` without explicit confirmation from the user
|