wslay
wslay copied to clipboard
Port to CMake
Hi,
I ported Wslay to use CMake as build system. I changed the API a little. You have to include wslay.h using #include <wslay.h> not #include <wslay/wslay.h>. I consider to have wslay.h in special directory unnecessary, because there will be only one .h file. I also fixed some compile warnings and I ported patch from https://github.com/benvanik (it should be possible to compile Wslay at Windows). I tested this build system only at Linux. I didn't do any changes of indentation.
Jiri
I did some small changes in README, NEWS, etc and I also deleted some useless files.
I created some issues for my wslay branch: https://github.com/jirihnidek/wslay/issues?state=open
Thank you for the patches. While I understand the usefulness of cmake, but I want to keep autotools files. Also I think storing libraries source files in lib folder is no so uncommon. Creating dedicated directory for header files has an advantage, for example, we can put header file autogenerated by build tools. I don't want to auto-generate wslay.h.
Hi, Thanks for your response. First, I want to say that I really appreciate your Wslay library. it seems that it will help me a lot. :+1:
When you claim that you understand the usefulness of CMake, then I don't understand why you want to keep Autotools files. Does it mean, you do not want to add support for CMake at all? BTW: I have experience with big projects and it is not wise to have more then one build system. Neither one build system is not well supported then.
CMake is IMHO much more better build system than Autotools is; e.g. generating Makefiles with autotools takes more time, then generating Makefiles and building whole project using CMake. On the other side CMake is more simple and flexible then Autotools, etc. From my point of view Autotools is like steam technology. :-)
May by it is not uncommon to have sources in lib folder, but is not to much descriptive. Anyway this is not anything essential for me. I can switch it back to lib.
I don't understand your claim about dedicated folder for wslay.h. Do you want or do you not want to autogenerate wslay.h? This is not anything essential for me too. It is easy to switch it back to <wslay/wslay.h>
BTW: there wasn't much activity for last few months in this project. Do you have any plans for this project?
Best regards,
Jiri
I am OK to add cmake support. But I'd like to keep autotools, just like curl project does. I'm not fully determined to get rid of autotools yet.
Choosing source directory name is subjective and is a good example of bikeshed. I have no reason to change lib to src at the moment, so leave it unchanged.
Actually, we have 2 header files in wslay directory. wslayver.h is generated from wslayver.h.in by build system, so that it contains correct version. You hardcoded version name in wslay.h, which is easily missed to update it. Since we have 2 files already, it is an obvious choice to use dedicated directory.
We have no update recently because there are nothing to do. No spec change in RFC, no interesting extension ATM.
BTW: I see two drafts of WebSocket extensions: http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04 http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11
Hi, pushed some changes to git (#include <wslay/wslay.h> and renaming src back to lib).
My standpoint about autotools: I'm not going to add back support for autotools, because I really do not like this technology.
I'm also interested in CMake support :) Just to make it clear, since I'm going to work on that: @tatsuhiro-t As I understand, your are OK with adding CMake support in addition to autotools. Is that right?
@wonder-mice yes. We accept cmake support patch, with the condition that autotools support is still in tact.