Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

cz.2| Jak to jest być deweloperem aplikacji wieloplatformowej - Deweloper vs Windows

Witam.

Zgodnie ze spisem treści kontynuuję serię, tym razem opowiem Wam o przygodzie budowania pliku binarnego EXE przy użyciu VirtualBox.

2. Ogólny proces paczkowania przez wirtualną maszynę

Na początku muszę pochwalić deweloperów projektu VirtualBox za świetną obsługę całego ich oprogramowania z poziomu shella - inaczej nie dałbym rady tego wystarczająco uprościć.

Dodatki VirtualBox dla systemu gościa również dużo wniosły do komfortu pracy pozwalając na dynamiczne skalowanie okna maszyny, ustawienie go na pełny ekran, czy na bardzo wygodne i wydajne udostępnianie plików po sambie.

1) Budowanie jednym kliknięciem - jak to działa?

Jak wcześniej chwaliłem deweloperów projektu VirtualBox to teraz pokażę za co dokładnie.

Listing build-windows.sh (Linux)

#!/bin/sh subget_git="/home/webnull/Praca/python/subget" # katalog projektu vm_name="Subget on windows" # nazwa maszyny rm "$subget_git/setup.exe" # kasuje plik # startuje maszynę /usr/lib/virtualbox/VirtualBox --startvm "$vm_name" & while [ True ] do sleep 1 # odczekamy sekundę kolejną oczekując na zakończenie budowania # sprawdza czy budowanie zostało zakończone - czy istnieje wynik w postaci setup.exe w lokalnym katalogu if [ -f "$subget_git/setup.exe" ] then sleep 5 # trzeba mieć pewność czy zapis się nie urwie przy natychmiastowym odłączeniu, lepiej chwilę odczekać bo różnie z systemami plików bywa /usr/lib/virtualbox/VBoxManage controlvm "$vm_name" acpipowerbutton # wyłącza delikatnie system w maszynie naciskając na przycisk zasilania break fi done

2) Budowanie paczki przy starcie systemu

W autostarcie systemu Windows XP siedzi skrót do pliku zapisanego w formacie batch.

Jego zawartość jest następująca:f:\subget\windows\nsi-paths-build.py ping 123.45.67.89 -n 1 -w 2000 > nul :: odpowiednik polecenia sleep echo off cd "c:\subget" del "c:\Program Files\Subget\*" /Q del "c:\subget\setup.exe" /Q del "C:\Subget\build\exe.win32-2.7\*" /Q copy f:\subget\usr c:\subget\usr copy f:\alang-py\usr c:\subget\usr copy f:\subget\subget.py c:\subget\subget.py copy f:\alang-py\usr\share\alang\python\alang.py c:\subget\alang.py copy f:\alang-py\usr\share\alang\python\alang.py c:\subget\usr\share\alang\python\alang.py copy f:\alang-py\usr\share\alang\python\alang.py "C:\Subget\build\exe.win32-2.7\alang.py del c:\subget\install.sh del c:\subget\README del "c:\subget\commit-copy" del "c:\subget\install-dependencies.sh" cd c:\subget c:\subget\cx_freeze_build_windows.py build "C:\Program Files\NSIS\makensis.exe" "f:\subget\windows\installer.nsi" copy "c:\subget\setup.exe" "f:\subget\setup.exe" f:\subget\setup.exe pause

1> Generowanie listy plików do zapakowania dla instalatora NSIS
f:\subget\windows\nsi-paths-build.py, proces zostanie opisany w następnych częsciach serii

2> Budowanie pliku binarnego EXE z postaci kodu Pythona
c:\subget\cx_freeze_build_windows.py build

3> Tworzenie pliku setup.exe przez skrypt NSIS
"C:\Program Files\NSIS\makensis.exe" "f:\subget\windows\installer.nsi"
Ten podpunkt zostanie opisany w dalszej części serii według spisu treści.

4> Pora na testy - instalacja i uruchomienie programu
f:\subget\setup.exe

Najbardziej bawi mnie w Batchu brak polecenia sleep które by zatrzymało parser na X milisekund.

Zaraz ktoś powie, przecież jest ten cudowny PowerShell. No ale Panie i Panowie zapominamy o podstawowej rzeczy - Batch jest podstawową powłoką w systemie Windows. Podstawowa powłoka SH w systemach Uniksowych jest stukrotnie bardziej zaawansowana, któraś strona z nas wciąż żyje w erze kamienia łupanego.

Na stackoverflow.com pewien użytkownik podsunął pomysł aby wywołać polecenie ping podając nieistniejący adres maszyny i w timeoucie ustawić tyle czasu na ile chcemy zatrzymać parser - ręce opadają przy tak śmiesznym rozwiązaniu.

Windows (Batch): ping 123.45.67.89 -n 1 -w 2000 > nul

Linux (Wszystkie powłoki): sleep 2

3) Tworzenie plików binarnych

W zasadzie mogę na początku odpowiedzieć na pytanie - dlaczego budować plik binarny skoro można uruchomić aplikację bezpośrednio z pliku z rozszerzeniem .py?

1. Wymagałoby to instalacji Pythona w systemie jego bibliotek
2. W Windows nie można używać plików skryptowych w "Otwórz za pomocą" - można otrzymać komunikat "Nie jest prawidłową aplikacją systemu win32"

A teraz przejdę do rzeczy.
Program cx_freeze umożliwia pakowanie plików Pythona do pliku EXE oraz umieszczanie wszystkich wymaganych do działania bibliotek w jednym katalogu z aplikacją - bardzo przydatne, ale trochę niepraktyczne.

Jednak na samym starcie pojawia się wiele problemów - słaba dokumentacja cx_freeze powoduje, że człowiek przeszukuje całą sieć aby znaleźć opis podstawowych funkcji programu.

Po wielu godzinach przeszukiwania sieci znalazłem rozwiązania na swoje problemy i tak oto stworzyłem skrypt do budowy plików binarnych projektu.

from cx_Freeze import setup, Executable import alang, os, sys exe = Executable( script="subget.py", base="Win32GUI", icon = 'f:\\Subget\\windows\\icon.ico' ) includefiles = ['alang.py', 'usr'] includes = ['usr'] excludes = [] packages = ['usr.share.alang.python', '_socket', 'socket', 'httplib', 'subprocess', 'os', 'time', 'urllib', 'hashlib', 're', 'zipfile', 'xml', 'StringIO', 'struct', 'usr.share.subget.plugins.napiprojekt', 'usr.share.subget.plugins.napisy24', 'usr.share.subget.plugins.allsubs', 'usr.share.subget.plugins.napisy_info'] setup( name = "Subget", version = "0.6", description = "A simple Subtitle downloading application for Linux, Unix and Windows", appendScriptToExe = False, appendScriptToLibrary = False, options = {'build_exe': {'excludes':excludes,'packages':packages,'include_files':includefiles}}, executables = [exe] )

Jednym z większych problemów cx_freeze jest potrzeba dodania wszystkich modułów dynamicznie ładowanych do projektu - owszem mogą one zostać automatycznie załadowane z plików projektu jednak co jeżeli projekt posiada wtyczki?

Jeżeli projekt posiada obsługę wtyczek to instalacja dodatkowej wtyczki może się okazać problemem, a mianowicie gdy zajdzie potrzeba użycia biblioteki niewymienionej wcześniej w projekcie to wtyczka nie ma prawa działać.

Powyższy skrypt po uruchomieniu poleceniem c:\subget\cx_freeze_build_windows.py build stworzy katalog build/exe.win32-2.7 w katalogu bieżącym. W zawartości znajdziemy plik wykonywalny .exe oraz masę bibliotek potrzebnych do jego uruchomienia.

Całość należy już tylko zapakować w instalator - a jak to zrobiłem to opiszę w następnej części.
 

Komentarze

0 nowych
Ryan   15 #1 13.07.2011 18:54

1. Sleep jest w pakiecie dodatkowych narzędzi dla systemów serwerowych.

2. Do skryptowania w Windows używa się JScript albo VBScript, bo mają dostęp do WMI.

3. Na nowszych Windowsach ludzie z powodzeniem stosują PowerShell. Niestety szansa, że jest zainstalowany na danym kompie, jest niska, więc lepiej używać rozwiązań z punktu 2.

4. Skoro masz i znasz Pythona, to po co używasz cmd? Żeby koniecznie pokazać, że to dla Ciebie nowe doświadczenie, które spowolniło portowanie kodu i w efekcie (oczywiście!) dowodzi, że w Windows to się wszystko robi źle? :)

webnull   9 #2 13.07.2011 19:38

@Ryan (redakcja) | 13.07.2011 18:54
Użyłem Batcha bo myślałem, że to co zamierzam zrobić nie przerośnie jego możliwości - jednak się myliłem jak widać.

JScript czy VBScript nie będę się specjalnie uczyć aby przenosić aplikację w Pythonie na Windows.

"1. Sleep jest w pakiecie dodatkowych narzędzi dla systemów serwerowych. "

Jedne narzędzia już instalowałem dla Windows Server 2003 które ktoś w tutorialu napisał, że znajduje się tam sleep i jakoś sleep wciąż nie działał.

Ryan   15 #3 13.07.2011 21:16

Ale CMD się uczyć mogłeś? :) Prawdopodobnie nie był dostępny w domyślnej ścieżce dostępu. To się naprawia czterema kliknięciami (jeśli się wie jak, ofcoz). Poza tym ciężko jest mi uwierzyć, że nie znasz ECMAScript. ;]

tfl   8 #4 13.07.2011 22:14

http://www.microsoft.com/download/en/details.aspx?id=17657

C:\Users\windows fanboy>sleep /?
Usage: sleep time-to-sleep-in-seconds
sleep [-m] time-to-sleep-in-milliseconds
sleep [-c] commited-memory ratio (1%-100%)

webnull   9 #5 13.07.2011 22:20

@Ryan (redakcja) | 13.07.2011 21:16
Myślałem, że zainstalowałem nie to co potrzeba a instrukcja na jakimś blogu była błędna tak więc znalazłem inny równie skuteczny sposób...

"To się naprawia czterema kliknięciami (jeśli się wie jak, ofcoz). Poza tym ciężko jest mi uwierzyć, że nie znasz ECMAScript. ;]"

No dobra znam, ale VBScript już nie :-)

matzu   5 #6 13.07.2011 22:53

Polecenie Sleep jak najbardziej działa, ale zamiast niego można też użyć polecenia Timeout. Jak podaje http://ss64.com/nt/timeout.html (bardzo dobra stronka) "Timeout.exe seems to consume less processor time time than Sleep.exe".

Ryan   15 #7 14.07.2011 20:12

@webnull: Ale nikt Ci nie każe pisać w dwóch językach jednocześnie, wystarczy w JScript. ;)

webnull   9 #8 15.07.2011 00:23

@Ryan (redakcja) | 14.07.2011 20:12
Jak na razie to pójdę za inną Twoją radą i zamiast Batcha użyję po prostu Pythona - będzie prościej i raczej obejdzie się bez problemów.

Także odnośnie rejestru to postaram się użyć modułu os.

W sumie to dzięki za dobre rady ;-)

  #9 15.07.2011 00:52

@Ryan (redakcja)
"2. Do skryptowania w Windows używa się JScript albo VBScript, bo mają dostęp do WMI."
Jak ktoś się uprze, to może korzystać z Pythona czy nawet Perla.
To nie jest żaden problem.
Nawet Scriptomatic je obsługuje (oczywiście obok VBScript i JScript).
Z resztą wypowiedzi się zgadzam.

Ryan   15 #10 15.07.2011 11:31

@Anonim: Patrz punkt czwarty w pierwszym komentarzu. ;) Pierwsza moja myśl to "po co pisać skrypty cmd, jak się używa Pythona". :]