Support for gyp? about ck HOT 6 CLOSED

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?

from ck.

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.

from ck.

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.

from ck.

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.

from ck.

Ah, interesting.

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

from ck.

@tobz - any updates on this?

from ck.