A mingw egy stabilnak mondott 5.0.0-ás installerrel ment fel - gondolom valami hasonló verzió lehet. A VC fordító a Visual Studio-val szállított darab volt, ez lényeges, mert ez MSVC90 névvel szerepel - és sokkal szigorúbb mint elődei, nagyon sok mindent nem fordít le, amit a régiek igen - cserébe nagyjából semmivel nem kompatibilis a vele készült bináris, mert a binárisba kiadott cuccok még jórészt MSVC80-nnal készülnek.
Perl(5.8.8)
A fordítása könnyű és gyors volt, a windowsos fordítás egész jól támogatott. Mingw-vel fordítottam, és működni látszott. Sajnos a cpan-ról ezt nem tudom elmondani, a msys-szel adott gzip nem igazán kezeli el a \ és a / közti különbséget ha a perl hívja - ne kérdezzétek miért, én se jöttem rá. Mivel a perl alapvetően előbb gzip-ezik és azután tar-ol, így a cpan sajnos működésképtelen volt.
Másik gondja a modulok megépítése volt - ebben sem igazán jeleskedett.
Eredmény: Kénytelen voltam ActivePerl-t feltenni, kizárólag a PPM miatt.
Ruby(1.8p114)
Ne tegyétek fel forrásból, főképp ha VS 2008-as C fordítótok van. Semmivel nem fog együttműködni, amit nem forrásból tettetek fel mellé. Komoly fordítási gondok vannak az openssl supporttal, és enélkül a gem csak féllábú óriás. Ezen felül minden olyan program, amit binárisból lehet leszedni, a régi fajta (msvcrt 8.0) ruby dll-eket keresi, és kiakad az újtól. Köztes megoldásként nem az one-click installer került fel, hanem a pure bináris. Van egy .reg fájlom, amivel be lehet izzítani pár extra funkcionalitást (automatikusan PATH-ba kerül, a parancssor ismerni fogja a .rb scripteket és futtatja mintha rendes script lenne, statikusan beállítja a 'RUBYOPT=rubygems' direktívát,...)
A gem leforgatása és felpakolása gyerekjáték bármelyik ruby verzióval, a gem-ekből pedig a hivatalos binárishoz vannak nativak, amiket nem kell forgatni.
OpenSSL(0.9.8g)
Könnyen lefordul és települ, több ilyen program kellene.
Apache(2.2.8)
Hát ez elég furcsa egy szerzet. Sokáig küzdöttem fordítási gondokkal, a Google pedig elég kevés támpontot adott. Annyi biztos, hogy a srclib\openssl alá az openssl build könyvtárából (tehát ahol azt leforgattuk) az inc32 és out32dll mappákat kell csak bemásolni (ez utóbbi az ntdll.mk-val fordított openssl-lel jő létre!).
Ezután a Makefile.win-t használva megépül az apr, apr-utils, apr-iconv és a lényeg, a httpd annak minden moduljával - ha szerencsénk van. Én körülbelül 3x futottam neki, mire sikerült, szóval türelem. A makefile helpje nem írja, de a parancssorhoz egy 'SSL=1' -et kell hozzácsapni, ha https support is kellene.
Python(2.6)
Ez a másik. Azért esett erre a szokatlan verzióra a választásom, mert ennél azt mondja a weblap, hogy nativan támogatva van a MSVC90-nel történő forgatás. Ez igaz is, csakhogy... :fejvakar: problémás tud lenni, ha teljes környezetet szeretnél.
Először is, a Tools\buldbot mappa alatti build.bat-ot használva meg kell építtetni az alap python-t. Ezután a tcl és tk könyvtárakat külön le kell forgatni (sajnos ez még nem igazán sikerül a python eszközének) és be kell telepíteni. A bzip2-t mingw-vel le kell fordítani (Makefile, majd a Makefile-libbz2_so -val a libbz2.lib-et is megépítjük, a keletkező libbz2.so.1.0.x az a libbz2.dll, de ez a pythonnak nem kell), majd visszamászunk a python könyvtárába. Itt a PCbuild mappában megnyitjuk a pcbuild.sln-t (devenv pcbuild.sln), és a bz2-t lefordítjuk. Build parancs előtt a Build->Configuration Manager menűben minden Win32|Release típusú projektet pippantsunk be, az összes többit meg ki. Ha szerencsénk van, a bz2 sikeressen megépül (PCbuild\bz2.pyd). A tcl-lel és a tk-val játszani kell egy kicsit, egyfelől meg kell nézni hova várja a libeket, másfelöl pedig a tcl és a tk build mappájából várja a megfelelő .lib fájlokat, nem pedig a telepített tk-ból. Fontos még, hogy a tk48.lib-et alapból nem linkeli, így azt a bz2 projekt tulajdonságainál kézzel hozzá kell adni (_tkinter, Jobb klikk, properties, C/C++ Properties, Linker, és a $(tcl48lib) sort kell kicserélni a tcl84.lib és a tk48.lib tartózkodási helyére, a PCbuild mappához képest relatívan). Az sqlite is hasonlóan megy.
Ha minden rendben leforgott, akkor jöhet a móka, a kacagás, és a telepítés. A setup.py benyujtja a Twix csoki felét, így marad a kézi mód.
Hozzunk létre valahol egy Python mappát (lehetőleg ezeket a programokat egy meghajtó gyökerébe tegyük, és még csak véletlenül se tegyük öket "Program Files"-szerű marháskodásokba, a szóköz hátrány).
Ebbe a python.exe pythonw.exe python26.dll kerül, valamint 4 további (még üres) mappa: dlls, include, Lib, Libs (case sensitive!). A dlls-be a PCbuild-ból kerülnek a .pyd végű cuccok, az include-ba a build mappa gyökeréből az Include + a PCbuild-ból a pyconfig.h, a Lib-be a build mappa Lib mappájának tartalma, a Libs-be a PCbuild-ból a python26.lib. Huh.
A pywin32 nevű projektet el kell felejteni, rémálom. A bináris ismételten nem szeret minket, a forrás pedig akkora borzalmakkal van tele, hogy aki nem ért a C-hez, bele se kezdjen, aki meg ért, az meg két napos szívásra számítson legalább - és igen sovány eredményre.
Egyelőre ennyi.
- hrgy84 blogja
- A hozzászóláshoz be kell jelentkezni
- 950 megtekintés
Hozzászólások
Tippek:
- A fordítási könyvtárakat ne töröljük, mert lehetnek olyan dolgok benne, amikre más programoknak szükségük van. Windowson nem egészen úgy fordulnak a dolgok mint linuxon, de majdnem.
- Ezt nem tudom eléggé hangsúlyozni: a cél mappák nevében ne használjunk szóközt, valamint lehetőség szerint ne temessük túl mélyre a felkerülő cuccokat - a PATH mérete korlátozott.
- A Visual Studio projektfájlokat is tartalmazó cuccoknál lehet vagánykodni az optimalizálásokkal, de ez kétes eredményekkel zárulhat.
- Legyen a pathban egy gvim, vagy valami olyan forráskiemelős szerkesztő, ami ismeri a Makefile és c szintaktikát is, hihetetlen segítség tud lenni.
- A hozzászóláshoz be kell jelentkezni