neelance / ffi_gen

A generator for Ruby FFI bindings, directly from header files via LLVM's Clang compiler
MIT License
88 stars 26 forks source link

Does this require clang 3.0 or at least 3.0? #23

Closed sheerun closed 9 years ago

sheerun commented 10 years ago

Newest clang is 3.5.0. Could you fix the readme if you meant "At least 3.0"?

neelance commented 10 years ago

Sorry, but I don't know which version works and which doesn't. I've written this project a long time ago and I'm not very active in the Ruby community any more... So I guess this project is open for adoption. Might you be interested?

sheerun commented 10 years ago

Yeah, sure. I want to develop service similar for https://rails-assets.org/ for FFI bindings.

neelance commented 10 years ago

Cool! Great idea. I'll move the project to a new "ffi-gen" organisation and give you admin access, okay?

sheerun commented 10 years ago

No need to. A collaborator is enough for now.

neelance commented 10 years ago

Okay, done. :-)

jvoorhis commented 10 years ago

Awesome! ruby-llvm is a fun project, but after Richard created ffi-gen, I knew there was real potential. With enough attention, this could really be a fun, hackable, universal alternative to SWIG.

Cheers,

On Wed, Nov 12, 2014 at 4:41 PM, Richard Musiol notifications@github.com wrote:

Okay, done. :-)

— Reply to this email directly or view it on GitHub https://github.com/neelance/ffi-gen/issues/23#issuecomment-62822258.

Jeremy Voorhis

neelance commented 10 years ago

@sheerun Feel free to do any changes you like, I'll complain if necessary. ;-) But I don't think I will, I am more than grateful that you take care of the project.

sheerun commented 10 years ago

Most likely my changes for ffi-gen will be cosmetic-only as for now I don't have much knowledge about llvm and low-level stuff in general. I'll try my best, tough :)

sheerun commented 10 years ago

Btw. should I release ffi-gen or rename it back to ffi_gen?

neelance commented 10 years ago

As far as I remember I started with ffi_gen and then renamed it to ffi-gen since the dash is more common. But I couldn't rename it on RubyGems. What do you think is the better approach?

sheerun commented 10 years ago

I think we should stay with ffi_gen, because we're not extending FFI

sheerun commented 10 years ago

You could rename repo back to ffi_gen I guess.

neelance commented 10 years ago

Done. Could you take care of the file changes?

sheerun commented 10 years ago

Yes, sure. But on the weekend.

On Thu, Nov 13, 2014 at 2:40 AM, Richard Musiol notifications@github.com wrote:

Done. Could you take care of the file changes?

— Reply to this email directly or view it on GitHub https://github.com/neelance/ffi_gen/issues/23#issuecomment-62827483.

sheerun commented 10 years ago

@neelance I rebased whole project removing commits that changed filenames. I hope you don't mind. Old code is in old-master branch. Do you think we can release current code? There were some fixes.

mvz commented 10 years ago

@sheerun that's in general not a wise thing to do because of people's git clones depending on the old master branch. You may run into trouble if/when those people make pull requests.

neelance commented 10 years ago

Yes, I also think that this might make (existing) pull requests more complicated. Reverting the changes or simply changing it back by hand might be better.

sheerun commented 10 years ago

@mvz @neelance Existing 2 pull requests are literally 3 commits with 3 lines changed.

Those pull requests would break anyway, because of renamed files. Anyone needs to rebase anyway.

I can rebase those 3 commits or even write them by hand.

sheerun commented 10 years ago

Besides, current pull requests don't include tests.

sheerun commented 10 years ago

First two changes: https://github.com/DAddYE/ffi-gen/commits/patch-1 Second change: https://github.com/jvoorhis/ffi_gen/commit/79cfb0973db4ed322bc941a34e5c56995c7f0ef3

The second change is so old there's not even need for rebase.

sheerun commented 10 years ago

@mvz @neelance Never mind, I rebased on old-master. It was easier than I thought. Sorry for this :)

What are the blockers for patch / minor release? What do you think?

mvz commented 10 years ago

I think #20 needs to be fixed.

sheerun commented 10 years ago

@mvz This is issue with already released ffi_gen version. Let's fix it in next patch. It's not a blocker.

mvz commented 10 years ago

Hm, I guess it depends on what your release goal is, then.

sheerun commented 10 years ago

To release two-year old fixes in master. One step a a time. Maybe some Travis suite before release could be helpful though.