Support windows about hammer HOT 15 OPEN

N.B. this is probably the single most important issue for me right now.

Have you thought of using gyp? I've mostly found it pretty personable across the major platforms so far.

from hammer.

(And by "have you thought of using" I of course mean "what would you think of a pull request to use" as well...)

from hammer.

I did a probe to see how difficult it would be to port hammer to windows. The following branch records the state of that probe:

https://github.com/uucidl/hammer/tree/win32-port

The code is not runnable yet, it's not tested etc.. but what compiles compiles.

The set up was attempting to build hammer with cl.exe with level 4 warnings.

Examples of issues:

• Asprintf, benchmark time measurement (addressed in my branch by introducing a platform layer)
• Lots of implicit truncation from int to uint8_t
• c99 stack allocated arrays with variable size i.e. local definitions like:

void f(int len) {
    char c[len]; /* not supported by cl.exe */
}

I thought of doing this probe then doing couple of pull requests with patches that would help with
the actual porting. What do you think of that? @thequux @abiggerhammer

Note, I did not work on build system stuff. Instead using a shell script for now:

cl.exe -nologo -EHsc -Z7 -Oi -GR- -Gm- -W4 -WX -wd4351 -wd4996 -wd4068 -wd4100 -c  ./modules/hammer/src/asprintf.c ./modules/hammer/src/platform_win32.c ./modules/hammer/src/allocator.c ./modules/hammer/src/benchmark.c ./modules/hammer/src/bitreader.c ./modules/hammer/src/bitwriter.c ./modules/hammer/src/cfgrammar.c ./modules/hammer/src/datastructures.c ./modules/hammer/src/desugar.c ./modules/hammer/src/glue.c ./modules/hammer/src/hammer.c ./modules/hammer/src/pprint.c ./modules/hammer/src/system_allocator.c ./modules/hammer/src/parsers/action.c ./modules/hammer/src/parsers/and.c ./modules/hammer/src/parsers/attr_bool.c ./modules/hammer/src/parsers/bind.c ./modules/hammer/src/parsers/bits.c ./modules/hammer/src/parsers/butnot.c ./modules/hammer/src/parsers/ch.c ./modules/hammer/src/parsers/charset.c ./modules/hammer/src/parsers/difference.c ./modules/hammer/src/parsers/end.c ./modules/hammer/src/parsers/endianness.c ./modules/hammer/src/parsers/epsilon.c ./modules/hammer/src/parsers/ignore.c ./modules/hammer/src/parsers/ignoreseq.c ./modules/hammer/src/parsers/indirect.c ./modules/hammer/src/parsers/int_range.c ./modules/hammer/src/parsers/many.c ./modules/hammer/src/parsers/not.c ./modules/hammer/src/parsers/nothing.c ./modules/hammer/src/parsers/optional.c ./modules/hammer/src/parsers/permutation.c -wd4201 -wd4200 -wd4204 -wd4324 -link ./builds/hammer.lib

from hammer.

That would be fantastically helpful. I had made some progress on a VS2013 build, but lost the hard drive it was on, so having a command-line way to start over is also great. Thanks!

from hammer.

Plus the command line version could be run from an appveyor job for continuous testing. I don't know yet how much time I can dedicate to this effort but I figure it can be done over the course of a few months.

from hammer.

Awesome. I've registered for appveyor and will get that set up ASAP.

from hammer.

Great! Actually I found out yesterday that Appveyor at cursory glance wants a vs project file. I'll be asking local experts to confirm if that is true, in which case hammer's build system will have to be taught how to generate these.

In the meantime I got a first working hammer.lib yesterday. Got it to parse a hello world.

Running unit tests is not yet possible. I believe they need glib?

I also haven't looked at how much effort is needed to generate language bindings.

from hammer.

Update: actually Appveyor's .yml file can run any build command perfectly fine.

from hammer.

The unit tests do currently use glib, and IIRC finding a usable glib is where I got balled up last time. We're certainly not married to glib, so if that's a showstopper for Windows users, switching to another testing framework is an option.

About half the language bindings use SWIG (for now, anyway) and I haven't looked into supporting that on Windows either, though I'm sure it's possible. The various bindings directories all have SConscripts detailing their build steps. If scons isn't a viable build system on Windows, then either we're going to need to maintain build scripts for the bindings or consider another build system. (I dunno, bazel?)

If you've got an appveyor .yml ready to go, I'll take that as a pull request now, otherwise I'll bang one in when I'm done with dayjob for the day. Thanks again for all the help!

from hammer.

So I created a pull request for the first step, which is figuring out what warnings to use and set up an appveyor.yml that will build all the files that currently can build on windows:

#137

Anonymous unions in header structs make the code not c99 and rather c11 by the way (referring to the first question about gnu99) ; thankfully MSVC supports anonymous unions.

from hammer.

Merged, thanks, and sorry for the delay!

from hammer.

I'll work on another patch proposal next weekend, most likely

from hammer.

Another proposal, this time addressing benchmarking, string formatting:

#138

from hammer.

Building and using hammer on windows is now possible using this PR:
#160

Just use tools\windows\build.bat to build the library.

What remains for announcing that hammer is supported on windows is to merge the above and include the windows port in the standard build system.

from hammer.

With this PR it is possible to use scons on windows as well:
#165

from hammer.