Previously, we blindly assume Ruby strings are UTF-8 and turn them
into Rust Strings (which *are* assumed to be UTF-8). This is clearly
unsafe so this commit adds some checks to cofirm that and generate
type errors appropiately.
These seem to be the appropriate way to check for `nil` and truthiness
of an object using the C API. I would assume that additional changes
have to happen since this touches the runtime extension, but I'm not
sure what to do.
For project name with more then one '-' using `sub` will only replace
the first occurence. This cause `copy_native` to be failed due to
`File.exist?` check failed. Use `gsub` instead to fix.
Apparently, `-m` still includes some 64 bit objects when running
dlltool. It leads to a linking error when compiling on 32-bit windows:
```
helix-runtime-0-6-3.i386.lib(dnekh.o) : fatal error LNK1112: module
machine type 'x64' conflicts with target machine type 'X86'
```
When analyzing the 32-bit lib file, you can see the 64-bit objects.
```
$ objdump -f helix-runtime-0-6-2.i386.lib
In archive helix-runtime-0-6-2.i386.lib:
dfrzt.o: file format pe-x86-64
architecture: i386:x86-64, flags 0x00000038:
HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x0000000000000000
dfrzh.o: file format pe-x86-64
architecture: i386:x86-64, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x0000000000000000
dfrzs00056.o: file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
```
This fix ensures we only run the 32-bit dlltool when building the 32-bit
native lib file
Since we already have the `Cargo.toml`, we don't actually need the
user to pass the project name. Further more, the build task doesn't
actually work correctly if you pass any name _other than_ what is
in your `Cargo.toml` (as seen in #92).
Fixes#110.