Open tribusonz-2 opened 2 months ago
Additional information.
It is expected that more extension libraries with this syntax will be available in the future.
I stated this definitively, but this is the only syntax that will work. It's also a "de facto bug fix."
The RDoc parser only checks words, not C syntax. Therefore, it seems possible to write code that is passed by the compiler but ignored by the RDoc parser. If it's readable, it's a bit "fashionable".
A sample is shown below:
// (foo.c)
#define RDocDummy 0
void
Init_foo(void)
{
rb_cFoo = rb_define_class("Foo", rb_cObject);
#if RDocDummy
rb_define_method(rb_cFoo, "bar", foo_bar, 0); // in define.c
#else
InitVM(Define);
#endif
}
// (define.c)
/*
* call-seq:
* bar -> String
*
* This is a test.
*/
static VALUE
foo_bar(VALUE self)
{
return rb_str_new_cstr("hello!!");
}
void
InitVM_Define(void)
{
rb_define_method(rb_cFoo, "bar", foo_bar, 0);
}
In the current version of RDoc, when searching for class definition APIs such as
rb_define_class
andrb_define_method
in a C file, if a match is found in that file, it seems to only accept the class and method definitions in that file. This means that no matter how the method is defined in other C files, it will be ignored.A mechanism will needed that to first gather elements from the C file and determine whether they are properly defined as classes. In this case, the parse tree would be desirable.
rb_xYYY
variables used as object entities are basically the global variables, so they must be declared asextern
when defining classes at the C level. However, this way does not work in outer method definitions (#pack/#unpack, etc.) because these "global variables" are not defined as classes.In C, global variables must be initialized. A popular solution is to do the initialization in a single C file.
This allows you to initialize variables as needed.
In Ruby, C's global variables are definitions, which means they have a different meaning than initialization. Now below, definition in single file, RDoc is well parse here:
However, a library that could become a small framework (such as image processing) is unlikely to be a single C file. That is, it needs to be improved.
Below is a typical way I write it, and it is an example of an extension library that uses Professor Oura's FFT in Ruby. The compiler passes it, but RDoc doesn't.
It is expected that more extension libraries with this syntax will be available in the future. You may want to reconsider RDoc as well.