walker1011 / snappy

Automatically exported from code.google.com/p/snappy
Other
0 stars 0 forks source link

Windows compile fix #63

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Please see attached patch fixing compilation with Visual Studio 2008 (and 
likely others)

Original issue reported on code.google.com by eilem...@gmail.com on 20 Jul 2012 at 12:01

Attachments:

GoogleCodeExporter commented 9 years ago
Hi,

Your patch does not apply to the source distribution; you are patching a file 
that is not included in the source, but generated at configure time.

In fact, the #if 1 you are removing is explicitly generated by configure (set 
to #if 1 or #if 0) based on whether stdint.h is available or not, so if you 
have a file that looks like #if 1 but the compiler does not have stdint.h 
available, you have done something wrong at configure time.

Original comment by se...@google.com on 20 Jul 2012 at 12:05

GoogleCodeExporter commented 9 years ago
Ok, fair enough. 

The file is part of snappy-1.0.5.tar.gz, though. I used the tarball as a base 
to compile the snappy code in a CMake environment, that is, I bypassed the 
autoconf stuff. (see 
https://github.com/Eyescale/Equalizer/tree/master/libs/co/compressor)

Original comment by eilem...@gmail.com on 20 Jul 2012 at 12:09

GoogleCodeExporter commented 9 years ago
Wow, you're right, it really is included in the tarball. It shouldn't be; I'll 
address that in a separate bug. I'm sure there is some sort of autotools magic 
I'm rubbing the wrong way; the file should be installed in make install, but 
not included in the tarball.

If you want to bypass autoconf, you'll need to edit snappy-stubs-public.h (and 
other files autogenerated by autoconf, such as config.h) yourself. Simply 
change #if 1 to #if 0 (effectively what you did) and you should be fine.

Original comment by se...@google.com on 20 Jul 2012 at 12:13

GoogleCodeExporter commented 9 years ago
I'm not an autoconf type of person, but this stuff shouldn't need to be 
configured. In my projects, I can get away with '#if _MSC_VER' and other 
predefined macros: 
https://github.com/Eyescale/Lunchbox/blob/master/lunchbox/types.h

Original comment by eilem...@gmail.com on 20 Jul 2012 at 12:16

GoogleCodeExporter commented 9 years ago
That's fine if you only need to support one or two platforms. If you want to 
support the wide arrays of different systems and compilers out there, depending 
on this sort of knowledge (“MSVC doesn't have stdint.h, except if it's above 
version 12.31”) simply doesn't scale, which is why autoconf simply does a 
test instead (compile against stdint.h and see if it exists).

It's a shame autoconf doesn't integrate well with MSVC, essentially forcing the 
use of two distinct build/configure systems if you want to support both Windows 
and other platforms. I'm sure one could argue equally well if this is MSVC's 
fault or autoconf's fault; in any case, we don't really support MSVC too well 
at this point, simply because it's so hard to support when you don't live in a 
Windows world every day.

Original comment by se...@google.com on 20 Jul 2012 at 12:25

GoogleCodeExporter commented 9 years ago
Try the link below for MSVC-compatible version of Snappy. I have also published 
NuGet packages for C++ and .NET, so that compiling the source code isn't 
necessary in most cases.

http://snappy.angeloflogic.com/

Original comment by robert.v...@gmail.com on 6 Mar 2014 at 10:09