I’m writing this as a reminder to myself, first of all because there is no documentation about how to embedded Ruby into a C++ application despite of the Ruby interpreter source files, secondly because when you start a sentence saying “first..” you need a second sentence saying “secondly…”.
The fast way to explain what you need to do:
ruby_options receive argc/argv as parameters, they are used like the Ruby interpreter would do, a void pointer is returned. The void pointer returned is a Node, it represents the Ruby code compiled and ready to run.
Notice “-enil”, if you don’t pass any argument the Ruby VM will crash without further explanation. In my example I want to execute some Ruby code located into a string, not a separated file, so I can’t pass the file path into options array because there’s no file, so -enil says “Execute this code: ‘nil’“.
You can use the void pointer returned by ruby_options into two functions, ruby_run_node and ruby_exec_node, the difference is that ruby_run_node executes the node then clean up the VM, so any other call to the Ruby C-API will cause a crash, ruby_exec_node just execute the node and keeps the VM alive for a future use.
Now with all in place, you can call rb_eval_string_protect to execute some ruby code and all other rb_* functions found on ruby.h to do whatever do you want, at least those rb_* functions have some documentation into README.EXT file found on Ruby source code.
After some months I finally got the committer rights on WebKit project :-), my first commit of course was the most traditional one, add myself on commiters.py :-P, hope to do more useful commits in a near future :-).
Don’t include myself in this group, I’m a long time KDE user and I don’t hate it despite of some annoying bugs, but I’m a heavy icecream user anyway :-).
What I have to say isn’t exactly about icecream, but about icemon, the nice GUI used to monitor icecream networks. But what’s wrong with it? Nothing! I’m a KDE user and the KDE dependency doesn’t bother me at all, but days ago tired of listen people (non-KDE users) complaining about the KDE dependency I decided to stop with all this and strip the KDE dependency from icemon even if the final result wont provide much difference to me.
After 1 hour of work I could finally say: “Mission accomplished!” and went to tell some coworkers at INdT that they owe me some beers. Some commits later to polish the fork and done… the Qt version is identical to the KDE one but without the kdelibs dependency.
This new baby is now called Iceberg and lives happy on Git-Hub, the name was a suggestion from setanta, just a word similar to icemon, nothing special.
So if you use icecream and don’t want to install kdelibs to see your icecream network, enjoy!
By a release I mean, I tagged the git repository with some version number (0.8), so you still need to download the sources from git if you want to test it. I wont spend my free time to create a website nor distro packages very soon, because I think that for while is better to spend my time coding than creating cosmetic things for a tool not production ready yet.
Ah, I almost forgot to say, meique is a pet project of mine, result of my will to have a more than reasonable building tool for C and C++, a really good one. I’m doing it on my free time and hope to finish it some day, hehe.
Ok, back to the main subject, it’s not production ready… by production ready I mean, if you want to use meique in a near future the best thing to do is to try to port your project to meique and report any bugs and wishes, so bugs can be fixed and wishes turned into reality.
So, what meique can do until now?
Out of source builds.
Find installed packages using pkg-config as backend.
Support projects with multiple source directories.
Decide if a file need to be recompiled by their contents, not by their timestamp.
Multiple jobs at once.
Detect the file dependencies and also use this information the decide if a file needs to be recompiled.
Automatic creation of the following targets: all and clean (install and uninstall not done yet).
Scopes for OS, compiler and build types, like the ones used in qmake.
What it can't do yet?
Probably there are some (maybe many?) bugs, because I did only few tests and I'm still to lazy to convert my manual tests into automatic tests.
There's no equivalent helper function to cmake configure_file function.
There's no windows port yet, to create it is a matter of create an os_windows.cpp which implements the OS interface, i.e. few
functions inside a namespace (rm, mkdir, cd, pwd, etc).</li>
There's no install function yet, I need to think a good API for it to support Mac OSX frameworks, simple UNIX installs and the mess found in Windows systems, so I wont implement anything until I have a clear and simple API for it in my mind.
Support for tests, something like the add_test function of cmake.
Documentation! Currently the only documentation is the source code itself, mainly meiquescript.cpp and the meique.lua files used to compile meique itself.
I’m talking about my pet project called meique, yes, this is yet another build tool.
The project is going a “bit” slow, I can summarize this situation in numbers, the project had 15 commits so far, 4 in 08/2009, 4 in 12/2009 and 7 in 04/2010. In other words, 4 commits, 4 months doing nothing, 4 commits, 4 months doing nothing, 7 commits, …
As you can see there is a pattern in meique development, every commit represents 1 month doing nothing! But this isn’t my fault, ok.. is my fault, anyway I want to break this pattern, no… no… I’m going to break this pattern!! at least I hope so.
Besides all development slow down I achieved some goals with those 15 commits:
The basic architecture to provide the basic functionality is done, or almost done :-).
Meique can now compile basic hello worlds \o/.
So what's missing and what's next?
Missing? A lot of things. My current implementation plan is:
Implement the source directory structure replication, used to the separated build dir compilation feature.
Create a very basic preprocessor, just to identify the dependencies of a C++ file on each run.
Use md5 or a faster hash algorithm to identify when a file needs to be recompiled.
Support multiple jobs, -jN option.
Redo this list with four more items.
For anyone interested on meique, take a look at gitrotious project page.