En la publicación de blog anterior, discutimos las diferentes variantes de compilación de Windows que admite PostgreSQL. En esta publicación, discutiremos cómo, como desarrollador basado en Unix, puede verificar si su parche podría funcionar en Windows. (Para simplificar, diré "Unix" para referirme a Linux, BSD, macOS y similares).
En primer lugar, existen algunas formas de verificar su parche sin necesidad de tener Windows.
Si su parche toca el sistema de compilación, por ejemplo, al agregar nuevos archivos, o más probablemente al agregar condicionales, nuevas opciones de compilación o lógica ad-hoc adicional, podría romper los scripts de compilación de MSVC, que analizan los archivos MAKE de Unix, como comentamos. ultima vez. Pero también puede ejecutar esos scripts en Unix. No hay (casi) nada específico de Windows en ellos, ya que todo lo que realmente hacen es analizar un conjunto de archivos y producir otro. Puedes simplemente correr
perl src/tools/msvc/mkvcbuild.pl
y mira lo que pasa. Esto funciona a partir de la confirmación 73c8596. (Tal vez guarde su trabajo de antemano, porque esto podría sobrescribir algunos archivos generados para que los use su configuración local que no es de Windows). Esto producirá archivos de proyecto para Visual Studio con los que no puede hacer mucho, pero puede verificar si el script se ejecutó, puede comparar la salida antes y después, o si ha realizado "ediciones ciegas" a cualquiera de los archivos bajo src/tools/msvc/ puede verificarlos hasta cierto punto.
Otra forma es ejercitar las opciones de compilación que normalmente se asocian con Windows. Cuál de estos es útil depende de lo que cambie su parche. Por ejemplo, las compilaciones de Windows con HAVE_UNIX_SOCKETS indefinido, por lo que puede valer la pena probarlo manualmente si está realizando cambios en el código de red. (Pero esto va a desaparecer, ya que Windows realmente admite sockets de dominio Unix ahora). De manera similar, HAVE_WORKING_LINK no está definido en Windows, aunque el impacto de eso es pequeño (y también está desapareciendo; a veces, una consecuencia de escribir publicaciones de blog como esta es descubrir que los problemas que quería describir no deberían estar allí en primer lugar, y vas a arreglarlos). Puede cambiar ambas opciones editando src/include/pg_config_manual.h . Otra opción importante es EXEC_BACKEND , que reemplaza el estilo Unix fork() llamar con un fork() más exec() implementación que se puede asignar a CreateProcess() en Windows Esto en realidad se rompe sorprendentemente rara vez, pero si lo hace, puede depurarlo y arreglarlo por completo en un sistema Unix. Para habilitar EXEC_BACKEND , puede editar src/Makefile.global y agrega -DEXEC_BACKEND a CPPFLAGS , o tal vez agregue una definición a src/include/pg_config_manual.h . (No estoy seguro de por qué esto es diferente de los otros; tal vez otra cosa para arreglar en algún momento. [actualización:también corregido])
Cuando se agoten estas opciones, quizás sea el momento de poner en marcha un sistema Windows real. Quiero discutir dos opciones que están fácilmente disponibles para el desarrollador ocasional. Primero, puede descargar una imagen de demostración de Windows de Microsoft e importarla a VirtualBox o algo similar. Los enlaces actuales para eso que puedo encontrar son:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
El segundo de estos está destinado a la prueba del navegador, por lo que quizás el primero sea mejor ahora, pero la ruta de prueba del navegador ha sido popular durante algún tiempo. Estas son copias de evaluación gratuitas, pero lea la licencia usted mismo.
En segundo lugar, puede lanzar una instancia en la nube en un proveedor de computación en la nube. No voy a nombrarlos, pero ya sabes quiénes son.
Cuando tenga el sistema operativo Windows funcionando, le recomiendo instalar MSYS2. (El primer enlace de descarga anterior de Microsoft también tiene Visual Studio instalado, si lo prefiere). Use un navegador (probablemente Internet Explorer o como se llame ahora) para ir a msys2.org, ejecute el instalador y en unos minutos tendrá listo un entorno MSYS2/MinGW completo. Siga las instrucciones del sitio web msys2.org para actualizar el administrador de paquetes. Luego, abra un shell MinGW (no MSYS2) desde el menú Inicio y ejecute lo siguiente para obtener los paquetes necesarios para el desarrollo de PostgreSQL:
pacman -S git
Ahora puedes git clonar el repositorio. Mientras eso 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 es una variable de entorno que se establece para usted, así que escriba los comandos de esa manera. (Será diferente para MinGW de 32 y 64 bits). Los paquetes sin prefijo son paquetes MSYS2 (es decir, Cygwin). Vea la parte 1 nuevamente si esto es confuso. En este punto, tendrá un entorno de compilación MinGW completo para PostgreSQL. Puede ejecutar configure, make, make check, etc. Es posible que se requieran paquetes adicionales para algunas opciones de compilación, pero no todas las opciones funcionan; por ejemplo, no Readline (use Cygwin para eso).
En la siguiente parte de esta serie, analizaré las opciones de compilación automática/integración continua para Windows que se pueden usar para verificar parches.
