Benjamin Kusin

The sparkey and snappy dependencies were supposed to have been removed for v.1.0, which would make a Windows build a lot easier, but the sparkey source directory is still present....

Got it, thanks. I am going to attempt to actually port to Windows, not merely build in MinGW. If I succeed, I'll write about it here.

I've changed my mind about porting - I've found out that it is often possible to link a Visual Studio project to `.a` files built with MinGW because C does...

I can now successfully build libpostal.dll.a. Seems to me that now that I've got `libpostal.dll.a` I should be able to use the API. I want to know if any of...

I actually don't need to port the download script. I'm building in MinGW, remember. One thing I encountered is that we need to `__declspec(dllexport)` whatever functions are supposed to be...

Had to add some `DLLEXPORT`s to the functions called in the test source files. I got build errors if I didn't. I'm leaving them for now, but we'll have to...

The Windows executable (built in Visual Studio) will think that `/opt/libpostal_data` is in the same directory as itself. But copying the data directory to the executable's directory isn't helping and...

You're right, the issue had something to do with the "-DLIBPOSTAL_DATA_DIR=..." from the CFLAGS in Makefile.am. The problem is that even if the slashes are converted, the right separator on...

Upon closer examination, I misdiagnosed this. `fopen()` works. By the way, a forward slash as a path delimiter works on Windows, too. What's actually happening during the loading of `address_parser_vocab.trie`...

Yes, they are the correct size. I've found the problem. Get this: There are 2 calls to `file_read_uint32` before the call to `file_read_chars`. Those two calls each read 4 bytes,...