Similar to c3d566332, the core methods have become more complicated (and are also checked at compile-time). This will give a more consistent experience across scripts.
Fixes#1563
Have been messing with this function in the dfhack repl and when it returns nil it's hard to know what that means unless you have also already read the code. So this handles a couple spots in `unit_ishostile` that previously just returned false-ey `nil`s to return `false`
If DOWNLOAD_RUBY is set to OFF, the build will not attempt to download
a prebuilt libruby.so and not fire a warning that one is not present.
This may be desired if one wants to link dfhack against a newer system
libruby.so, now that dfhack supports ruby 2.x and also supports linking
against system libruby (at least, on Linux), as per the following commit:
df9b5bca73
This also allows the dfhack build to proceed without network access
(once all submodules have been fetched), which at least some Linux
distributions, like Fedora, require.
By default DOWNLOAD_RUBY is set to ON, so this should not change
the behavior of default builds.
I tested that when DOWNLOAD_RUBY is set to OFF, dfhack still launches
and that the Ruby plugin still functions, e.g. by running
```rb_eval puts('Hello world.')``` in the dfhack console.
These have different values on x64 Ruby 2.x (see USE_FLONUM in ruby.h in the
ruby source). This was causing dump_rb_error to crash, since it was walking an
array until it got to Qnil (but thinking Qnil was 4 instead of 8) and trying to
print each element as a string. There were probably more subtle issues with
Qnil and Qtrue being wrong too.
- Add uint64_t
- Add special case for long on different platforms
- Require OS and architecture to be specified
NOTE: integer alignment on x64 is probably still incorrect
- Passing the architecture is needed to determine sizeof(long)
- Passing the OS prevents potential issues when cross-compiling between Windows
and non-Windows (although this is unlikely)