Support for gyp?

[tobz]

Hey there!

First off, thank you for all the hard work put into this library. The documentation is great, and where it falls down, the source is easy to understand. On top of all of that... it solves problems for me so I can focus on what I'm actually trying to do. :)

I've been using ck in a side project of mine that I decided to use gyp as the build system for. I basically got to a point where I have a gyp project file that I wrote for ck that compiles it on my architecture so I can use it as a native dependency in the main project.

So, long story short: would supporting gyp ever be something you'd consider? I realize there's already a good chunk of Makefile hand-crafted loving going on, but I would envision it as a "gyp and make living side by side" sort of thing. It's a single file addition, and as far as I can see, it has enough flexibility to tailor compiler/linker flags as needed for various platforms... and the logic to actually figure out what platform it's on.

(to add context, I'm asking because I'm curious if I should bother trying to make my project handle ck's usage of make directly, or if it's worth trying to port what ck's Makefile does now into a gyp project file, and then submit THAT as a PR to ck)

[sbahra]

Hey Toby,

Glad you find CK useful, thanks for the kind words. I'm totally unfamiliar with gyp and don't see myself picking it up any time soon, perhaps the best route is to point me to a fork with the appropriate gyp glue already in place (assuming you've done the work there).

Otherwise, are you having any issues with the existing build infrastructure?

[tobz]

So, the only reason I see this working is simply that it's mostly set and forget? Like, if there's new source files, just add them in. If you need to add a different compiler flag for a certain architecture, just add it in to the existing flags override for that architecture. I think maintaining it going forward would be trivial, and could reasonable be "at your own risk" usage. Hell, I'd certainly be willing to get CC'd on issues with it, but, obviously, this is all up to you.

I don't have a representative project file to show you... yet. I did the minimum viable configuration so there's no per-architecture compiler flags override, etc, which I think is important to demonstrate. I also haven't figured out yet if there's a way to replicate the preprocessing that the configure script does (re. ck_md, the memory model detection, etc) with gyp alone.

I didn't have any issues in particular with the existing build infrastructure. It's just a whole lot more seamless to add a project dependency to an existing gyp project IF that dependency is also a gyp project. It's smart enough to treat it as a transitive build target which means I don't have to shove configure/make commands anywhere. It essentially makes it a two line include to a project: the dependency itself and adding its include directory to the include search path. That's why making ck gyp-enabled is attractive to me.

[tobz]

Also, separately, and I should have mentioned this earlier: gyp is essentially a native build system generator. So it's a tool, with its own configuration format, for generating Makefiles or Visual Studio solution files, and then also be able to invoke those tools for you, etc etc.

So, that said, supporting gyp would, I think, actually get ck closer to being easily built under Windows. The code itself, I have no idea, but it looks like there's no infrastructure in ck for building on Windows, which gyp could actually help with.

[sbahra]

CK should compile with mingw/cygwin. Would you be open to creating a patch for us to see whether it will truly be fire and forget? Worst case, the official repository could point to your fork...best case, we merge it in.

[tobz]

Ah, interesting.

Yeah, I'd totally be down for that. Give me some time.

[sbahra]

@tobz - any updates on this?