Dois builds de fonte: só converter, ou uma pilha anfitriã completa

Quando transferir em vez de compilar

O zip oficial nos GitHub Releases é o par suportado neste site: um relinker e as bibliotecas anfitriãs correspondentes da mesma etiqueta. Compilar da fonte é opcional. Use-o quando altera o código, reproduz um commit nomeado, ou o zip publicado não traz um pedaço anfitrião que o BUILD.md diz que pode compilar.

Transferência: par zip oficial · Caminho casual: Releases oficiais, depois configuração.

Compile da fonte quando

• Contribui um patch e precisa de compilar a árvore que editou.
• Um relatório público nomeia um commit ou etiqueta que não é o par do zip publicado.
• Precisa de uma biblioteca anfitriã que o zip de versão não envia para o seu SO — só se o BUILD.md documentar esse alvo.

Os dois caminhos de compilação documentados

Só relinker: converter ELF convidado → PE ou ELF anfitrião

BUILD.md: este modo constrói a ferramenta de conversão sem inicializar submódulos nem configurar SDL, Vulkan, FFmpeg, FreeType ou o recompilador de shaders. Precisa de CMake, um compilador C++20 e uma ferramenta de build. Python 3.9 ou mais recente activa os testes Python. O binário fica em build-relinker/core/relinker/relinker (relinker.exe no Windows com Ninja).

cmake -S . -B build-relinker -G Ninja -DCMAKE_BUILD_TYPE=Release -DANYPS5_RELINKER_ONLY=ON -DBUILD_TESTING=ON
cmake --build build-relinker --parallel
ctest --test-dir build-relinker --output-on-failure

• A saída é x86-64: ELF Linux por omissão, PE Windows com --windows, ou Mach-O com --macos.
• Os títulos convertidos ainda precisam de bibliotecas de sistema compiladas para o SO de destino e de um anfitrião x86-64 compatível. O modo só-relinker não constrói essas bibliotecas.
• As versões enviam bibliotecas anfitriãs só para Linux e Windows.
• Use um directório de build separado se depois correr o build completo.

Build completo: ferramentas mais libs / runtime

Uma pilha executável começa com git submodule update --init --recursive. Com BUILD_TESTING=OFF por omissão, cmake --build não produz as bibliotecas corrigidas. BUILD.md: cada biblioteca em core/libs/prx está EXCLUDE_FROM_ALL, por isso o passo explícito --target libs é obrigatório. Os títulos carregam os .prx corrigidos de build/core/libs/libs.

git submodule update --init --recursive
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++
cmake --build build --parallel
cmake --build build --target libs --parallel

• Requisitos nomeados no main actual e em v0.1.3: x86-64, Git, CMake 3.22.1 ou mais recente, Ninja, C++20. Abra o BUILD.md para os pacotes do SO.
• Depois de uma alteração de biblioteca, saltar --target libs testa os binários anteriores.
• USAGE.md: copie build/core/libs/libs/*.prx para o libs/ do título. Use bibliotecas compiladas para o SO de destino.
• Self-build Windows: copie também libgcc_s_seh-1.dll, libstdc++-6.dll e libwinpthread-1.dll dessa toolchain ao lado dos PRX corrigidos. O carregador não pesquisa o PATH; DLLs em falta podem aparecer como erro 126 mesmo com o .prx presente. Os zips de versão já as incluem.

Noções de reprodutibilidade

Os ativos oficiais de versão registam uma etiqueta e um commit (web-release.json / release.json no trabalho Pages). Se compilar, anote a etiqueta ou o commit da árvore que construiu. Um número de PR não é uma revisão: commits posteriores e resoluções de conflitos mudam a árvore.

• Faça checkout de uma etiqueta (por exemplo v0.1.3) ou de um commit nomeado e registe git rev-parse HEAD.
• Não salte --target libs quando precisa de uma pilha anfitriã executável.
• Mantenha o relinker, as bibliotecas corrigidas e (no Windows) as três DLL de runtime MinGW da mesma compilação.
• Abra o BUILD.md que veio com essa árvore. O main actual documenta mais toolchains Windows do que o ficheiro de v0.1.3.

macOS e outros anfitriões

README e BUILD.md: o build só-relinker corre no macOS, incluindo Apple silicon, com AppleClang das ferramentas de linha de comandos do Xcode. USAGE.md: --macos escreve Mach-O x86-64, que corre sob Rosetta no Apple silicon; --to-rosetta baixa instruções que a Rosetta não tem. Os títulos convertidos ainda precisam de bibliotecas de sistema para o SO de destino. As versões enviam essas bibliotecas só para Linux e Windows. Uma compilação só-relinker bem-sucedida, ou uma conversão Mach-O, não é um runtime de jogo macOS suportado e não é Playable. O desconhecido permanece desconhecido.

Depois do build

Um self-build não é o zip oficial. Continua a converter um ELF limpo e a organizar app, libs/ e app0/ da mesma forma. A diferença é a origem dos dois ficheiros anfitriões: o seu directório de build em vez do par de ativos do GitHub. Uma janela não é Playable.

• O modo só-relinker dá-lhe um conversor. Não substitui o zip das bibliotecas anfitriãs.
• Um build completo ainda precisa da estrutura de configuração e da mesma ordem de observação no primeiro lançamento.
• O 126 ou 193 do Windows após um self-build continua a ser um problema de estrutura ou de DLL em falta — veja a resolução de problemas. Não o trate como fase de título.

Um self-build não é Playable

Passar o ctest ou produzir app.exe / app.elf confirma esses passos. Não sobe nenhum título. Cite a etiqueta ou o commit que compilou na página do título e no Game bring-up. Esta página não afirma que o áudio Linux está corrigido em v0.1.3. Game bring-up.

Transferência: par zip oficial · Configuração: estrutura e ordem de observação no primeiro lançamento · Resolução de problemas: 193, 126, limites do anfitrião

Fontes originais

• BUILD.md no main actual
• BUILD.md na etiqueta v0.1.3
• USAGE.md (opções de conversão, estrutura de runtime, --macos)
• README (só-relinker no macOS, incluindo Apple silicon)