silentsound.net

Although I mentioned in my previous post that PyFriBidi isn’t the Swiss Army knife of Python language support, it’s still rather useful as far as RTL language support goes given the alternatives (i.e., none).  Using it, though, requires that little step called “compiling”, which turns out to be far from a bundle of joy on Windows.

I ended up compiling it using Visual Studio 2003 to keep with the cardinal rule of using the same compiler as Python itself (2.5 in my case). Given the number of bug reports for MinGW/Cygwin, I don’t think either of those would have made this any easier. Instead of having you follow 500 steps, I’m just going to refer you to a build script to handle all this. I need to compile this frequently enough that I didn’t want to follow a bunch of steps myself either.

The script does assume you have:

• Visual Studio 2003 to compile extensions for Python 2.5
• CVS command-line utilities (available here)
• diff command-line (available here)
• Python 2.5

The README file covers how to configure the various settings in the script. You are more than welcome to rewrite this as a Python script should a VBScript somehow insult your OSS vibe. If you rewrite it in Perl, I’ll sacrifice a kitten.

For those curious, the script does the following:

• Cleans up any output files
• Downloads FriBidi2 from CVS if not found
• Sets up the output directories
• Copies in the config.h and fribidi-config.h configuration files
• Copies in the custom PyFriBidi source files
• Fixes the pow references in packtab.c
• Reverts to the 0.10.9 behavior of exporting the UTF-8 functions
• Excludes the toupper definition for Windows (it’s part of the standard library)
• Fixes the formatting of the export definition file to work with Visual Studio’s linker
• Fixes the benchmark file to correctly obtain user time on Windows
• Builds and run the Unicode data generators
• Builds the FriBidi library
• Builds the FriBidi utility applications
• Builds PyFriBidi
• Runs the FriBidi tests

All of these changes to the source code should be forwards-compatible since the script checks the original file before applying them. I had to make enough changes to the PyFriBidi2 source code that I ended up including a patched version with the build script (see their tracker for the history here). I’d recommend running a diff between this copy and the latest trunk just to make sure the two haven’t deviated whenever you use this.