On Tue, Jan 15, 2013 at 9:14 PM, Wayne Meissner <wmeissner@gmail.com> wrote:

> On Wednesday, 16 January 2013 10:09:39 UTC+11, Luis Lavena wrote:

>>
>> Noticed in the example that result of compilation is left in the ext
>> folder. Assume that is to avoid clash wih ruby trying to load the shared
>> library?

>
>
> You're reading too much intent into a quick&dirty late night hack :-)
>

Don't underestimate the power of late night hacking ;-)

I was wondering since I started to work on a rake-compiler replacement
that works outside-in called gem-compiler:

https://github.com/luislavena/gem-compiler

But it collects compiled artifacts from known locations defined in the
gemspec like require_paths:

https://github.com/luislavena/gem-compiler/blob/master/lib/rubygems/compiler.rb#L26-L28

That is why I peek into the final placement of the compiled shared object.

> It leaves the library where it is because that was the simplest thing that
> worked.  Once it worked as a proof of concept, I shipped it, as I figured we
> can refine it as we go.
>

Couldn't agree more :)

> I think for the next version, I'll move to a rake task style, rather than
> generating a Rakefile (i.e. similar to what ruby-llvm does).  It increases
> the transparency of what is happening, which will make it easier to debug
> when things don't work.  The current way is based on the idea of "build
> something like mkmf, but for FFI".

I think pre-compiled gems generated with ffi-compiler could be
processed with gem-compiler too, to provide pre-compiled binaries for
some platforms where gem compilation might be difficult.

Not just talking about Windows, also pre-compiled for other platforms.

Again, will take a look on Windows later today and chime in, hope you
don't mind :)

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry