Generates the Makefile for your extension, passing along any options and preprocessor constants that you may have generated through other methods.
The target
name should correspond the name of the global function name defined within your C extension, minus the Init_
. For example, if your C extension is defined as Init_foo
, then your target would simply be “foo”.
If any “/” characters are present in the target name, only the last name is interpreted as the target name, and the rest are considered toplevel directory names, and the generated Makefile will be altered accordingly to follow that directory structure.
For example, if you pass “test/foo” as a target name, your extension will be installed under the “test” directory. This means that in order to load the file within a Ruby program later, that directory structure will have to be followed, e.g. require 'test/foo'
.
The srcprefix
should be used when your source files are not in the same directory as your build script. This will not only eliminate the need for you to manually copy the source files into the same directory as your build script, but it also sets the proper target_prefix
in the generated Makefile.
Setting the target_prefix
will, in turn, install the generated binary in a directory under your RbConfig::CONFIG['sitearchdir']
that mimics your local filesystem when you run make install
.
For example, given the following file tree:
ext/ extconf.rb test/ foo.c
And given the following code:
create_makefile('test/foo', 'test')
That will set the target_prefix
in the generated Makefile to “test”. That, in turn, will create the following file tree when installed via the make install
command:
/path/to/ruby/sitearchdir/test/foo.so
It is recommended that you use this approach to generate your makefiles, instead of copying files around manually, because some third party libraries may depend on the target_prefix
being set properly.
The srcprefix
argument can be used to override the default source directory, i.e. the current directory. It is included as part of the VPATH
and added to the list of INCFLAGS
.
The version of the Marshal
format for your Ruby.
Returns true
if the file or directory may be renamed by RNFR.
Escapes all possible entities
Unescapes all possible entities
Does this dependency request match spec
?
NOTE: match?
only matches prerelease versions when dependency
is a prerelease dependency.
Returns a new lazy enumerator with the concatenated results of running block once for every element in lazy.
["foo", "bar"].lazy.flat_map {|i| i.each_char.lazy}.force #=> ["f", "o", "o", "b", "a", "r"]
A value x returned by block is decomposed if either of the following conditions is true:
a) <i>x</i> responds to both each and force, which means that <i>x</i> is a lazy enumerator. b) <i>x</i> is an array or responds to to_ary.
Otherwise, x is contained as-is in the return value.
[{a:1}, {b:2}].lazy.flat_map {|i| i}.force #=> [{:a=>1}, {:b=>2}]
Emit a sequence with map
and tag
Called when a map starts.
anchor
is the anchor associated with the map or nil
. tag
is the tag associated with the map or nil
. implicit
is a boolean indicating whether or not the map was implicitly started. style
is an integer indicating the mapping style.
See the constants in Psych::Nodes::Mapping
for the possible values of style
.
Here is a YAML document that exercises most of the possible ways this method can be called:
--- k: !!map { hello: world } v: &pewpew hello: world
The above YAML document consists of three maps, an outer map that contains two inner maps. Below is a matrix of the parameters sent in order to represent these three maps:
# anchor tag implicit style [nil, nil, true, 1 ] [nil, "tag:yaml.org,2002:map", false, 2 ] ["pewpew", nil, true, 1 ]
Called when a map ends
Builds a methods for level meth
.
Returns the major part of File_Stat#dev
or nil
.
File.stat("/dev/fd1").dev_major #=> 2 File.stat("/dev/tty").dev_major #=> 5
Returns the major part of File_Stat#rdev
or nil
.
File.stat("/dev/fd1").rdev_major #=> 2 File.stat("/dev/tty").rdev_major #=> 5
The main loop performed by a DRbServer’s internal thread.
Accepts a connection from a client, and starts up its own thread to handle it. This thread loops, receiving requests from the client, invoking them on a local object, and returning responses, until the client closes the connection or a local method call fails.