Na postagem anterior do blog, discutimos as diferentes variantes de compilação do Windows que o PostgreSQL oferece suporte. Neste post, discutiremos como, como desenvolvedor baseado em Unix, você pode verificar se seu patch pode funcionar no Windows. (Para simplificar, direi “Unix” para significar Linux, BSD, macOS e similares.)
Primeiro, existem algumas maneiras de verificar seu patch sem precisar ter o Windows.
Se o seu patch afetar o sistema de compilação, por exemplo, adicionando novos arquivos ou, mais provavelmente, adicionando condicionais, novas opções de compilação ou lógica ad-hoc adicional, ele poderá quebrar os scripts de compilação do MSVC, que analisam os makefiles do Unix, conforme discutimos última vez. Mas você também pode executar esses scripts no Unix. Não há (quase) nada específico para o Windows neles, pois tudo o que eles realmente fazem é analisar um conjunto de arquivos e produzir outro. Você pode simplesmente correr
perl src/tools/msvc/mkvcbuild.pl
e veja o que acontece. Isso funciona a partir do commit 73c8596. (Talvez salve seu trabalho com antecedência, porque isso pode substituir alguns arquivos gerados para serem usados por sua configuração local não Windows). Isso produzirá arquivos de projeto para o Visual Studio com os quais você não pode fazer muito, mas você pode verificar se o script foi executado, pode comparar a saída antes e depois ou se fez “edições cegas” em qualquer um dos arquivos em
src/tools/msvc/ você pode verificá-los até certo ponto. Outra maneira é exercitar as opções de compilação normalmente associadas ao Windows. Qual deles é útil depende do que seu patch muda. Por exemplo, o Windows compila com
HAVE_UNIX_SOCKETS undefined, portanto, testar isso manualmente pode valer a pena se você estiver fazendo alterações no código de rede. (Mas isso está indo embora, já que o Windows realmente suporta soquetes de domínio Unix agora.) Da mesma forma, HAVE_WORKING_LINK é indefinido no Windows, embora o impacto disso seja pequeno (e também está desaparecendo; às vezes uma consequência de escrever posts como este é descobrir que os problemas que você queria descrever não deveriam estar lá em primeiro lugar, e você vai corrigi-los). Você pode alterar essas duas opções editando src/include/pg_config_manual.h . Outra opção importante é EXEC_BACKEND , que substitui o estilo Unix fork() chamar com um fork() mais exec() implementação que pode ser mapeada para CreateProcess() no Windows. Isso realmente quebra surpreendentemente raramente, mas se isso acontecer, você pode depurar e corrigi-lo inteiramente em um sistema Unix. Para ativar EXEC_BACKEND , você pode editar src/Makefile.global e adicione -DEXEC_BACKEND para CPPFLAGS , ou talvez adicione uma definição a src/include/pg_config_manual.h . (Não tenho certeza por que isso é diferente dos outros; talvez outra coisa para corrigir em algum momento. [atualização:também corrigido]) Quando essas opções estiverem esgotadas, talvez seja hora de ativar um sistema Windows real. Eu quero discutir duas opções que estão facilmente disponíveis para o desenvolvedor casual. Primeiro, você pode baixar uma imagem de demonstração do Windows da Microsoft e importá-la para o VirtualBox ou algo semelhante. Os links atuais para isso que posso encontrar são:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
O segundo deles é destinado ao teste do navegador, então talvez o primeiro seja melhor agora, mas a rota de teste do navegador é popular há algum tempo. Estas são cópias de avaliação gratuitas, mas leia a licença você mesmo.
Segundo, você pode iniciar uma instância de nuvem em um provedor de computação em nuvem. Não vou nomeá-los, mas você sabe quem são.
Quando você tem o sistema operacional Windows em execução, recomendo instalar o MSYS2. (O primeiro link de download acima da Microsoft também tem o Visual Studio instalado, se você preferir.) Use um navegador (presumivelmente Internet Explorer ou o que quer que seja chamado agora) para ir para msys2.org, execute o instalador e em alguns minutos você terá um ambiente MSYS2/MinGW completo pronto. Siga as instruções no site msys2.org para atualizar o gerenciador de pacotes. Em seguida, abra um shell MinGW (não MSYS2) no menu Iniciar e execute o seguinte para obter os pacotes necessários para o desenvolvimento do PostgreSQL:
pacman -S git
Agora você pode clonar o repositório. Enquanto isso corre…
pacman -S ${MINGW_PACKAGE_PREFIX}-gcc ${MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-libxslt ${MINGW_PACKAGE_PREFIX}-openssl bison flex make diffutils MINGW_PACKAGE_PREFIX é uma variável de ambiente definida para você, então digite os comandos assim. (Será diferente para MinGW de 32 bits e 64 bits.) Os pacotes sem prefixo são pacotes MSYS2 (ou seja, Cygwin). Veja a parte 1 novamente se isso for confuso. Neste ponto, você terá um ambiente de compilação MinGW completo para PostgreSQL. Você pode executar configure, make, make check e assim por diante. Pacotes adicionais podem ser necessários para algumas opções de compilação, mas nem todas as opções realmente funcionam; por exemplo, sem Readline (use Cygwin para isso). Na próxima parte desta série, examinarei as opções de integração automática/contínua para Windows que podem ser usadas para verificar patches.
