Think of the children!
gamagan opened this issue · comments
I've been reading about Hobbes for days because I've been so excited about the language and it's features. But, it's been a mirage, because I develop on Windows, and this is macos/unix only. Dang. Think of the children and consider making this available on Windows, so I can bring it up to my team.
I thought that kids these days were all on macOS. Maybe I'm just getting old?
Are there particular features you're most interested in using? We might be able to get there soon in small steps.
I looked at porting to Windows a while back, but I'm a little out of touch with Windows build tools and common infrastructure (e.g. building LLVM with MSVC). Also our CI tool (travis-ci) only supports Linux and macOS, though I think there must be a Windows CI option for github (especially now that Microsoft owns it).
I've done some work on an alternative back-end (replacing LLVM) which is implemented here in a header-only lib in include/hobbes/mc/ and I have confirmed that bit works on Windows (x86_64). I could port hobbes to that back-end, which would make it much more lightweight (LLVM is a heavy dependency) and also it'd work on Windows.
I've been thinking about splitting those header-only bits into a different project, which would make them easier to use (and also easier to get parts working on Windows one by one).
"I thought that kids these days were all on macOS."
Only the rich kids.
"Are there particular features you're most interested in using?"
For my team's usecase, we maintain a bunch of web-services provided by the company. These 'front-end' web-services contact backends services to actually fetch the data. In order to get the data, we have to look at all kinds of rules and entitlements to determine if the client is able to access this data, and we have to return the correct version of the data, and we need to log info about the request/response, and it needs to be speedy, etc.
Hobbes sounds like it could help us deal with the complexity of all of this in an elegant way.
Thanks for considering it!
Interesting, that does sound similar to some of our use-cases. The data recording bits might be easier to isolate and get working on Windows independently. That's why I was considering splitting those parts out into an independent (lighter weight) library.
For low-latency evaluation of rules like you describe, we've been using large pattern match tables. That requires the whole compiler, so would need the whole thing translated.
Do you have experience doing automated builds on Windows? Maybe you have some advice to offer in terms of how I might set this up? If I could set something up to reliably build hobbes on Windows, I'd be happy to hack at the code to get it to work.
Do you have experience doing automated builds on Windows?
I'm afraid not. Our automated builds are Linux only.
Darn, so we are in the same boat then.
Are your request processors on Windows? How do you develop that part of your infra (if not with automated builds)?
I’m just trying to understand where hobbes would fit here exactly. Do you want to produce files from Windows? Maybe just talk over the network with a hobbes-enabled process on a Linux host? Or actually run queries on Windows hosts?
We develop on Windows, on Visual Studio, and deploy to production on Linux.
I did attempt to port Hobbes to Windows a while ago and ran into some obstacles:
- Some of the code uses gcc specific preprocessor macros, which I couldn't get Microsofts compiler to accept. This might be less of an issue now, because clang ist optionally available.
- Most of the used posix headers and functions could be easily ported since Windows also supports them with slight adjustments.
- I adjusted the build system to produce separate libraries for each of the subdirectories in lib/hobbes/, that had the advantage that some of the less portable ones (events, db, rpc) did not need to be ported immediately.
- Some of the platform specific code can be replaced by corresponding abstractions in LLVM on which Hobbes depends anyways.
With regard to continuous integration and Windows: In my experience it is quite easy to setup with https://circleci.com. I've done so for bazel based projects, but I wouldn't expect there to be a huge difference for CMake.
Thanks for going to all of that trouble and reporting back!
Good to know about circleci, I wasn't aware of that one. I did find a different service that offered Windows builds when I looked into this at one point but didn't get far enough to try it.
The macro set you highlighted is pretty important, although we could get rid of it if C++ ever supports static type reflection.
I found this comment from somebody else trying to reconcile gcc's handling of variadic macros with VC++, situation looks pretty grim:
https://stackoverflow.com/questions/9183993/msvc-variadic-macro-expansion