This patch for aspell 0.60.5 makes it possible to compile it natively on Win32. Tested configuration is Microsoft Visual C++ 2008, Win32/x64 targets, but as cmake is used for building, it should handle all other Win32 compilers more or less gracefully also.

Update: it appeared that there ARE existing some patches for aspell 0.60.5 for Windows/x64 support already - there are at least two patches in aspell tracker, see here and here. I do not have time for detailed comparison, but at a first glance they seem to be also OK, so it may make sense to have a look there also.

When compiling Psi for Windows/x64 using Visual C++ 2008 I had to recompile aspell also in order to add spell checking support to Psi, as to the best of my understanding there are no aspell libraries available for Windows/x64.

As aspell didn’t support native Win32 compilation in its current version, I had to patch it.

I decided to use cmake for Win32 build, as it has at least several advantages to the use of Makefile/vcprojs:

1. Easy support for all current and future versions of different Win32 compilers.
2. Easy maintenance - cmake allows to construct sources lists to build using simple but powerful syntax, this way it should be easy to maintain cmake build script.

I’ve tried to change as little as possible in original aspell code to make sure further maintenance is easy and also nothing is broken. The size of patch is quite large, but it’s due to changes in auto-generated code, as for all interface functions declspecs should be added to import/export them from DLL.

Current shortcomings of the patch are:

1. As I’m not familiar with code generation scripts aspell uses I cannot be sure I’ve fixed it in all necessary places to put ASPELL_API macro for exporting functions. While I successfully used resulting DLL in Psi, it uses only small part of aspell interface, so it’s still possible that some things can be missing.
2. As a consequence of (1), I had to change aspell.h after auto generation (to add ASPELL_API stuff there instead of including “settings.h”, as that include is unwanted in interface header) - this means changes will be lost on next auto generation.
3. Libraries names are inconsistent with *nix ones - I do not know cmake that well to produce two targets with identical name (also static library would clobber with import library of DLL), also I didn’t want to include versioning into cmake script - thus I ended up giving names “aspell_static.lib” and “aspell_shared.dll” to respective libraries.
4. Executables aspell, prezip-bin and word-list-compress are linked to aspell library statically, as they use a lot of internal functions from aspell library, and these functions have to be exported manually - that was not an option for me due to the lack of time.
5. I’m not sure “declspec” syntax is portable enough to other compilers on Win32, it may be necessary to adjust these parts of settings.h header if you try to compile it with compiler that does not understand “declspec” syntax for importing/exporting functions from DLL.
6. No installation is provided in build scripts.

Visual C++ 2008 specific issues

Please note that as of 26.11.2007 there’s no cmake release that supports Visual C++ 2008 - you need to use development version of cmake. Also compiler detection seems to be problematic, I had to add -G "Visual Studio 9 2008" option to run cmake successfully.

Additionally, even development version does not support x64 target. I used the following script to post-patch project files generated by cmake for Win32 target to compile as x64: for %%i in (*.vcproj *.sln) do sed --in-place 's/\/machine\:I386//; s/Win32/x64/' %%i.