zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

On Sun, Mar 7, 2010 at 9:45 AM, Brendan Kidwell <snarf@xxxxxxxxx> 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