On Sun, Mar 7, 2010 at 9:45 AM, Brendan Kidwell <sn...@glump.net> wrote: > At long last, I have a working NSIS-based installer for Zim 0.4x for > Windows. Thanks very much to Eugene Schava for submitting build-win32.py > back in January.
Nice ! I think many users will be very grateful. > Here's what I have: > * README-BUILD-win32.txt -- explains where to get all the dependencies > (GTK+, PyGTK, Bazaar, NSIS) and how to run the build and package scripts. > * build-win32.py -- I had to add a couple of lines of code here on top of > what Eugene wrote. > * create-zim-setup.nsi -- NSIS installer build script > * register-extension.nsh -- NSIS function to register a file type in the > Windows shell > * zim-logo-big.bmp -- big logo for Setup wizard > create-zim-setup.nsi creates an installer package (.exe) in > ./windows/release, with a size of about 17MB. > My questions are these: > Due to the excellent support of Windows from the Python ecosystem, very > little needs to be added to the pyzim source tree to support building a > binary for Windows and packaging for Windows. Therefore, we should integrate > my additions directly into the pyzim source tree. Correct? > If so, where exactly will they go? Right now I've got > README-BUILD-win32.txt > build-win32.py > --> in ./ > create-zim-setup.nsi > register-extensionnsh > zim-logo-big.bmp > --> in ./windows/build > Should *.nsi, *.nsh and *.bmp really in ./windows/build? Where would you put > them, Jaap, if you were doing this? I think I will merge build-win32.py with setup.py, so it can be called as './setup.py py2exe'. Also I will merge README-BUILD-win32.txt with the generic README.txt . For all windows specific build files I would put them directly under ./windows/ this directory would then be more or less parallel to the ./debian/ directory. The py2exe script could probably target ./py2exe/ as build directory. The installer itself should end up in ./dist/ like all other archives for distribution. (Only reason not to have py2exe target ./dist/ is that it does not produce a single file, but a directory.) > Is "README-BUILD-win32.txt" named correctly? (Again, it's a list of > instructions for installing dependencies and creating the installer > package.) > I assume I should follow standard Bazaar procedure outline here > http://doc.bazaar.canonical.com/latest/en/user-guide/sending_changes.html > to submit my changes to you, once I'm ready, yes? I see you already figured out how to push a branch. Just put in a merge request through launchpad when it is ready for public consumption. > What about the installer .exe file? Who will host that? I don't mind having > me personally take charge running the Windows build process a day or two > after I see you announce a new Zim version, but I think it ought to be > hosted directly at > http://zim-wiki.org/downloads/ > if 17MB isn't too much of a load on the web hosting provider. (If it is, > then let's keep it at Google Code where I published my installer for the > Perl version last year.) What do I need to do with my installer to get it > published on zim-wiki.org? Alternative Jaap if you have direct easy access > to a reliable Windows system, you can do the build and take me out of the > loop if you'd like. Looking at the hosting plan I would prefer keeping it a Google Code. Most linux users don't download directly from our site. But given the lack of a package management system on windows I suppose we would have to expect quite some direct downloads times 17Mb. I don't have a windows system available for private use, so if you are willing to support building windows releases I would be much obliged. > Oh and one more thing! There's a tiny bit in the NSIS script that's not > automated: the maintainer needs to manually enter the Zim version number and > the official date tag for this build into the script source before running > it. I don't have access to a Windows server that can perform automatic > builds in response to Jaap checking in new code in lp:zim, so I'm not > inclined to fix this shortcoming in the build process. If we DID want to go > with automated builds, I could probably fix it so it set the version number > and build date automatically. Comments on this, anyone? Not me - anyone else ? Regards, Jaap _______________________________________________ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp