Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document how to build larger Goji binding projects #7

Open
tel opened this issue Apr 5, 2015 · 2 comments
Open

Document how to build larger Goji binding projects #7

tel opened this issue Apr 5, 2015 · 2 comments

Comments

@tel
Copy link

tel commented Apr 5, 2015

I'm attempting to see how Goji scales to binding to a larger library—in particular, the Meteor framework. It's a significantly larger project than any of the example Goji bindings, but I don't think it's out of scope.

Unfortunately, I run into a lot of issues trying to figure out how to make Goji run with a larger project. As a simple example, it took me some time to realize that when breaking a binding into multiple modules I need to separately compile a .cmxs file for each module and then list them all to goji generate

ocamlbuild -use-ocamlfind all.cmxs  # depends on Tracker.ml
ocamlbuild -use-ocamlfind tracker.cmxs
goji generate -d bindings _build/tracker.cmxs _build/all.cmxs

I can try to dig into the Goji source more deeply to understand how everything is being generated, but it'd be nice to know if there are any larger bindings through Goji I could use as an example or if there is any documentation for how to use Goji "practically".

Thanks!

@klakplok
Copy link
Owner

klakplok commented Apr 6, 2015

Hi @tel. Goji was not designed to be restricted to small projects, but as you've already noticed people have only used it to bind small stand-alone libraries (at least for open source projects).

So the bad news is that you'll probably have to go through some not-so-tested (or documented) features. The good news is that you're coming at the right time, because I am actually resuming the work on Goji and browser bindings these days, so if you like the tool and wish to continue using it, I'll be there to assist a bit and fix things so you won't have to dive into the code.

Meteor's API seems reasonably typeable, so I think it's a good candidate for Goji. It would be a nice experiment, and it may help improve the tool at the same time. It also seems to me that the doc is reasonably formatted, so a first draft binding could be extracted automatically (to be proof read and edited by hand, of course, but it could save time).

I'll have a look at your binding in the coming days. In the mean time don't hesitate to ask questions or remarks (here or less publicly at your option).

@tel
Copy link
Author

tel commented Apr 8, 2015

Hi!

This is quite good timing then indeed. I'm beginning a new project which I think will involve some non-trivial javascript/front-end work. I decided to attempt a small bit of the Meteor binding because, as you noted, they tend to have rather good documentation and take somewhat less advantage of Javascript's dynamism.

I'm still evaluating technologies and I may just build a first version directly using Meteor since it'll be a faster early win, but I'd like to bring in advantages of typing and modularity so the OCaml binding could replace my code in time.

So, given feasibility moves forward, I'll be increasingly interested in using Goji to bind some kind of sufficient front-end technology to allow me to leverage OCaml. I'll be happy to talk—publicly—about my exploration here as well. At least that of which I'm at liberty to share.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants