Compiling a Hunspell DLL, step by step

[Update (18/8/10): since I posted this, some revisions to the Hunspell source in the meantime might make it easier to just use the libhunspell project file in the win_api sub-directory. As per my comment in response to Arnold below, this project in the v1.2.11 release builds fine for me ‘as is’.]

As I got asked, I thought I might as well make a separate post out of it, so here goes. To compile a new Hunspell DLL, you could do the following:

1. Make sure you have a suitable C++ compiler at the ready. I’ve no idea about C++Builder, but Visual C++ Express does the job fine, and it’s free.
2. Make sure you have something like the (open source) 7-ZIP installed so you can open a compressed tarball file (.tar.gz).
3. Download the Hunspell source from Hunspell’s Sourceforge homepage.
4. Extract said source to a suitable directory. If you inspect the extracted files, you’ll come across more than one MSVC project file — specifically, you should be able to find one for MSVC 6 in src\hunspell (hunspell.dsp) and a MSVC 2005 project group (‘solution’) in src\win_api (Hunspell.sln, hunspell.vcproj, libhunspell.vcproj, testparser.vcproj). Basically, Hunspell is a C++ library, though at some point, a new DLL project file with C exports (the one in win_api) was added to the standard distribution to make using Hunspell with (e.g.) Delphi simpler. Later still however, a C interface with slightly different signatures was added to the main source. Consequently, it doesn’t really matter which project file you choose — my wrapper supports DLLs produced by either. Also, while only the win_api project file is set to create a DLL by default, you’ll still have to fiddle about with it before getting it to compile, and once done, it will create a slightly larger DLL compared to the other one.
5. That in mind, load up MSVC Express, go to File|Open|Project/Solution…, and find your way to src\hunspell\hunspell.dsp.  Accept the resulting prompt to convert the project file to the newest format.
6. Go to Project|Add Existing Item, and from src\hunspell, choose every .cxx and .hxx file. I also suggest adding Hunspell.rc from src\win_api too.
7. Go to Project|Properties, select Configuration Properties in the tree view, then All Configurations in the Configurations combo box (the latter lies directly above the tree view). Next, change Configuration Type to Dynamic Library (.dll), before selecting  C/C++ in the tree view and setting Additional Include Directories to ..\win_api.
8. You should now be able to build the project, which will produce hunspell.dll under src\hunspell\Debug. To create a release build, select the Release configuration (most easily from the combo box immediately to the right of the ‘run’ toolbar button), and rebuild. This should cause another hunspell.dll to be created, only this time under src\hunspell\Release.

Arnold

Advertisements

Using Hunspell — a code page-aware wrapper

Yes, it’s been done before – indeed, I’ve used Brian Moelke’s simple Hunspell wrapper from a few years back myself – but a few posts on the Embarcadero forums in the past couple of months have prompted me to write up my own.

Basically, if you haven’t heard of it, Hunspell is the open source spell checking engine used in OpenOffice, and very good it is too, at least for English – I’ve found it much better than Ispell, for example, in terms of both speed and the quality of its suggestions.

The Hunspell source itself can be downloaded from SourceForge here – you’ll need a C++ compiler to build a DLL from it (VC++ Express is fine for this purpose, and so might C++Builder – I don’t know). Calling a resulting DLL is then fairly straightforward, though one slightly tricky thing – and where my own code has its main reason for being – is in using dictionaries with foreign code pages, such as a Greek dictionary on an English system. The difficulty here is that while Hunspell itself supports UTF-8 encoded dictionaries, most actually-existing ones have an ANSI encoding – and the strings you pass to the Hunspell engine must have the encoding of the dictionary being used, the engine itself doing no conversions. In light of that, my wrapper transparently does any needed conversions for you, with the key methods having Ansi and Unicode overloads when compiling in Delphi 2006 or 2007. Moreover, I’ve also tried to write the source in a D2009+ friendly manner too.

Naturally, it may turn out that no one but myself will find it useful though, but anyhow, it’s available here if you’re interested. The ZIP includes a demo app (as one might expect), together with a prebuilt Hunspell DLL compiled with the current-at-my-time-of-typing version of the Hunspell source, namely v1.2.8.