W poprzednim wpisie na blogu omówiliśmy różne warianty kompilacji systemu Windows obsługiwane przez PostgreSQL. W tym poście omówimy, w jaki sposób, jako programista oparty na systemie Unix, możesz sprawdzić, czy twoja poprawka może działać w systemie Windows. (Dla uproszczenia powiem „Unix” w znaczeniu Linux, BSD, macOS i podobne.)
Po pierwsze, istnieje kilka sposobów sprawdzenia łatki bez konieczności posiadania systemu Windows.
Jeśli twoja poprawka dotyka systemu kompilacji, na przykład dodając nowe pliki lub, co bardziej prawdopodobne, dodając warunki, nowe opcje kompilacji lub dodatkową logikę ad-hoc, może zepsuć skrypty kompilacji MSVC, które analizują pliki makefile Unix, o czym mówiliśmy ostatni raz. Ale możesz uruchomić te skrypty również na Uniksie. Nie ma w nich (prawie) nic specyficznego dla systemu Windows, ponieważ wszystko, co naprawdę robią, to parsowanie jednego zestawu plików i tworzenie innego. Możesz po prostu biegać
perl src/tools/msvc/mkvcbuild.pl
i zobacz, co się stanie. Działa to od zatwierdzenia 73c8596. (Może wcześniej zapisz swoją pracę, ponieważ może to nadpisać niektóre wygenerowane pliki, które są używane przez twoją lokalną konfigurację inną niż Windows). Spowoduje to utworzenie plików projektu dla programu Visual Studio, z którymi niewiele możesz zrobić, ale możesz sprawdzić, czy skrypt w ogóle działał, możesz porównać dane wyjściowe przed i po, lub jeśli dokonałeś „ślepych zmian” w którymkolwiek z pliki w src/tools/msvc/ możesz je do pewnego stopnia zweryfikować.
Innym sposobem jest ćwiczenie opcji kompilacji, które są zwykle związane z systemem Windows. To, które z nich jest przydatne, zależy od zmian w łatce. Na przykład Windows kompiluje z HAVE_UNIX_SOCKETS niezdefiniowane, więc ręczne testowanie może być opłacalne, jeśli wprowadzasz zmiany w kodzie sieciowym. (Ale to odchodzi, ponieważ Windows faktycznie obsługuje teraz gniazda domeny Unix.) Podobnie, HAVE_WORKING_LINK jest niezdefiniowany w systemie Windows, chociaż wpływ tego jest niewielki (i również zanika; czasami konsekwencją pisania postów na blogu, takich jak ten, jest odkrycie, że problemy, które chciałeś opisać, nie powinny tam występować, a idź je naprawić). Możesz zmienić obie te opcje, edytując src/include/pg_config_manual.h . Inną ważną opcją jest EXEC_BACKEND , który zastępuje uniksową fork() wywołaj za pomocą fork() plus exec() implementacja, która może być zmapowana do CreateProcess() w systemie Windows. To faktycznie psuje się zaskakująco rzadko, ale jeśli tak się dzieje, możesz debugować i naprawić to całkowicie w systemie Unix. Aby włączyć EXEC_BACKEND , możesz edytować src/Makefile.global i dodaj -DEXEC_BACKEND do CPPFLAGS , a może dodaj definicję do src/include/pg_config_manual.h . (Nie jestem pewien, dlaczego różni się to od pozostałych; być może kolejna rzecz do naprawienia. [aktualizacja:również naprawiona])
Kiedy te opcje się wyczerpią, być może nadszedł czas, aby uruchomić prawdziwy system Windows. Chcę omówić dwie opcje, które są łatwo dostępne dla zwykłego programisty. Najpierw możesz pobrać demonstracyjny obraz systemu Windows od firmy Microsoft i zaimportować go do VirtualBox lub czegoś podobnego. Aktualne linki, które mogę znaleźć to:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Drugi z nich jest przeznaczony do testowania przeglądarki, więc być może pierwszy jest teraz lepszy, ale trasa testowania przeglądarki jest popularna od jakiegoś czasu. Są to bezpłatne kopie ewaluacyjne, ale prosimy o samodzielne zapoznanie się z licencją.
Po drugie, możesz uruchomić instancję w chmurze u dostawcy usług w chmurze. Nie będę ich wymieniał, ale wiesz, kim są.
Jeśli masz uruchomiony system operacyjny Windows, zalecam zainstalowanie MSYS2. (Pierwszy link do pobrania powyżej od firmy Microsoft ma również zainstalowany program Visual Studio, jeśli wolisz). Użyj przeglądarki (prawdopodobnie Internet Explorer lub jakakolwiek teraz się nazywa), aby przejść do msys2.org, uruchom instalator i za kilka minut będzie mieć gotowe pełne środowisko MSYS2/MinGW. Postępuj zgodnie z instrukcjami na stronie internetowej msys2.org, aby zaktualizować menedżera pakietów. Następnie otwórz powłokę MinGW (nie MSYS2) z menu Start i uruchom następujące polecenie, aby pobrać pakiety potrzebne do rozwoju PostgreSQL:
pacman -S git
Teraz możesz git sklonować repozytorium. Podczas gdy to działa…
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}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-libxslt ${MINGW_PACKAGE_PREFIX}
MINGW_PACKAGE_PREFIX jest zmienną środowiskową, która jest ustawiona dla ciebie, więc wpisz takie polecenia. (Będzie inny dla 32-bitowego i 64-bitowego MinGW.) Pakiety bez prefiksu to pakiety MSYS2 (tj. Cygwin). Zobacz ponownie część 1, jeśli jest to mylące. W tym momencie będziesz mieć pełne środowisko kompilacji MinGW dla PostgreSQL. Możesz uruchomić konfigurację, zrobić, sprawdzić i tak dalej. W przypadku niektórych opcji kompilacji mogą być wymagane dodatkowe pakiety, ale nie wszystkie opcje faktycznie działają; na przykład brak Readline (użyj do tego Cygwin).
W następnej części tej serii przyjrzę się opcjom automatycznej kompilacji/ciągłej integracji dla systemu Windows, które można wykorzystać do weryfikacji poprawek.
