MinGW package guidelines (Português)
Esta página explica como escrever PKGBUILDs para software em execução no Windows usando o GCC. Existem duas opções para criar software para o Windows no Linux:
- mingw-w64: fornece cadeia de ferramentas de 32 e 64 bits com suporte a secure crt, Vista+ API, DDK (ReactOS) e DirectX (WINE). Para uma lista completa dos recursos e diferenças suportados com o antigo MinGW.org, veja aqui. Disponível em mingw-w64-gcc.
- MinGW: fornece cadeia de ferramentas de 32 bits com suporte limitado a DirectX. Ele também sofre com a quebra de longa duração na implementação do armazenamento local de encadeamento e no suporte à biblioteca de ponto flutuante. Foi removido dos repositórios oficiais e do AUR.
Nomenclatura de pacote
Um pacote para mingw-w64 deve ser nomeado mingw-w64-pkgname. Se uma variante estática do pacote está sendo compilado, acrescente o sufixo de nome de pacote com -static (veja abaixo para os casos nos quais isso é necessário).
Empacotamento
O empacotamento para pacotes de plataforma cruzada pode ser bastante complicada, pois há muitos sistemas de construção diferentes e peculiaridades de baixo nível. Tome nota das seguintes coisas:
- sempre adicione mingw-w64-crt ao
depends, a menos que ele dependa de outro pacote que implicitamente depende dele - sempre adicione mingw-w64-gcc ao
makedepends, a menos que esteja usando mingw-w64-configureAUR ou mingw-w64-cmakeAUR - sempre adicione , e ao
options - sempre use o original e adicione ao fim do
- sempre use e siga o original do pacote oficial
- sempre compile as versões 32 bit e 64 bit das bibliotecas
- sempre coloque todas as coisas sob o prefixo
/usr/i686-w64-mingw32e - sempre use
anycomo a arquitetura (exceto que o pacote contém executáveis que devem ser executados no sistema de compilação) - sempre compile os binários compartilhados e estáticos, a menos que eles conflitem
- considere a remoção de documentação desnecessária (, )
- considere usar mingw-w64-configureAUR para compilação com scripts de configuração
- considere usar mingw-w64-cmakeAUR para compilação com CMake
- considere usar ou [link quebrado: package not found] para compilação com QMake
- considere usar opções de compilação (geralmente nomeadas com CFLAGS, CXXFLAGS) quando nenhum sistema de compilação adequado foi fornecido
- considere remover símbolos explicitamente com em loop for como demonstrado nos exemplos de PKGBUILD abaixo.
- considere usar o comando find para interagir com já que todas DLLs, bibliotecas estáticas ou executáveis podem residir em localizações apropriadas.
- se o binário é uma DLL, use
- se o binário é uma biblioteca estática, use
- considere usar o comando find para interagir com já que todas DLLs, bibliotecas estáticas ou executáveis podem residir em localizações apropriadas.
- se um pacote é modular (requer certas dependências de compilação, mas tais dependências são opcionais para o usuário final) adicione essas ao
makedependseoptdepends. Certifique-se de subtrai-los dodependsse estiver atualizando um pacote existente. Exemplo disto em uso: [link quebrado: package not found], - se um pacote instala um script , crie um link simbólico para
$pkgdir/usr/bin/${_arch}-*-config - se um pacote usa autoconf, defina explicitamente no para contornar o bug #108405 do autoconf ou usar mingw-w64-configureAUR
Como mencionado acima, os arquivos devem ser todos instalados em /usr/i686-w64-mingw32 e . Especificamente, todas as DLLs devem ser colocadas em , pois são bibliotecas dinâmicas necessárias no tempo de execução. Seus arquivos correspondentes devem ir para /usr/*-w64-mingw32/lib. Por favor, exclua qualquer documentação desnecessária e talvez outros arquivos de . Os pacotes de compilações cruzadas não são destinados ao usuário, mas apenas ao compilador e à distribuição binária, e, como tal, você deve tentar torná-los o menor possível.
Sempre tente combinar o em seus pacotes mingw-w64 com o dos pacotes comuns correspondentes nas repositórios oficiais do Arch Linux (e não nos repos de teste). Isso garante que o software de compilação cruzada funcione exatamente da mesma maneira no Windows, sem nenhum erro inesperado. Se os pacotes no Arch estão desatualizados, geralmente há uma boa razão e você ainda deve seguir a versão do Arch em vez de usar o release upstream mais recente. Se o pacote nativo correspondente estiver no AUR, não será necessário seguir esta política de versão, pois muitos pacotes do AUR são muitas vezes órfãos ou não são mantidos.
Exemplos
Os exemplos a seguir tentarão cobrir algumas das convenções e sistemas de compilação mais comuns.