mirror of
https://github.com/google/brotli.git
synced 2026-09-22 14:45:51 +00:00
[PR #24] visual studio support (again) #606
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Original Pull Request: https://github.com/google/brotli/pull/24
State: closed
Merged: No
this pull request is the same as @r-lyeh request #5 from October last year, with just some little modifications of mine.
There are three problems when trying to compile the C++ brotli encoder with Microsoft Visual C++ 12.0:
"fast_log.h" is missing the assert header include:
enc/fast_log.h(44) : error C3861: 'assert': identifier not found
the use of function rand_r() inside "block_splitter.cc" makes the compiler raise "identifier not found". As @r-lyeh suggested, rand_r could be replaced by a combination of srand() and rand().
enc/block_splitter.cc(100) : error C3861: 'rand_r': identifier not found
in "write_bits.h", the attempt to import "endian.h" fails on Windows, which unfortunately does not provide this header. Besides, the include does not seem to be necessary here. In fact, the macro "IS_LITTLE_ENDIAN" which is used in write_bits.h is already specified inside "port.h" header, which is among the includes.
enc/write_bits.h(24) : fatal error C1083: Cannot open include file: 'endian.h': No such file or directory
As a workaround, @r-lyeh proposed a new portable "endian.h" header file. However, for the sake of detecting the byte order, I believe it would be sufficient to presume that when _WIN32 (or _WIN64) is defined, then the byte order will always little endian (ok, the XBox 360 has a big endian processor, but...).
So I added such Windows-specific #ifdef to "port.h", and removed @r-lyeh's "endian.h" file.
I would like to emphasize that it's only by using the patch by @r-lyeh (with or without the superfluous endian.h) that I was able compile the brotli Python extension on the Windows platform.
I have tested both gcc (via Cygwin or MinGW) and several Microsoft Visual C/C++ compilers.
Cygwin's gcc (POSIX) was able to compile only through @r-lyeh patch.
The MinGW-w64 gcc (targeting win32) was not able to compile even when using @r-lyeh's patch, so I gave up on gcc and tried one of MS Visual Studio compilers.
I first tried MS Visual Studio 2008 (the same used for Windows Python 2.7), but it was missing stdint.h header...
So I tried to force Python's distutils to use Visual Studio 2010. This time stdint.h was found, but the math.h module was missing the binary logarithm (log2) function... (of course, that could be rewritten as log(v)/log(2) or something).
Finally, I tried to make Python use MS Visual Studio 2013 as a compiler, and this time the Python extension compiled correctly, again thanks to @r-lyeh patch.
The brotli decoder (which is written in plain C) does compile successfully on Windows. It is the encoder, written in modern C++, which has the above mentioned issues. It would be nice if you could add Windows among the supported platforms. I'm interested because we are trying to use the brotli Python bindings in fontTools for decoding/encoding WOFF2.
Thanks a lot for your work.
Cosimo