Modernize project structure

[furunkel]

This PR modernizes the project structure.

Among other things:

• Use gemspec, bundler and rake-compiler
• Put C files into /ext
• Get rid of m4 (use C preprocessor)

The gem name is now changed to 'sdl2', as it should reflect the directory and module structure (which is sdl2 and SDL2, respectively.

[ohai]

Thank you for your PR.

First of all, m4 is used because yard does not understand the C macros. Now the code processed by m4 is used to generate documents. Probably this change breaks the document. How about that?

[furunkel]

It does, yes. But as far as I can tell only the keycodes are affected. This is a sacrifice well worth making, considering that those codes are self-explanatory anyway.

[ohai]

The change affects not only the doucmentation of keycode constants. All m4 macros are used for the documentation of constants. For example, the change also affects SDL2::Mixer constants.

[furunkel]

Really ? How so ? The only two m4 macro occurrences I spotted are: /* define(DEFINE_MIX_INIT',rb_define_const(mMixer, "INIT_$1", UINT2NUM(MIX_INIT_$1))') */ and /* define(DEFINE_MIX_FORMAT',rb_define_const(mMixer, "FORMAT_$1", UINT2NUM(AUDIO_$1))') */

[ohai]

Do you run yard by yourself? I don't find the way to run yard from rake after applying your change.

For example your change drops the documentation of SDL2::Mixer::INIT_OGG.

[furunkel]

Yard task is now there. Although it prints quite some warnings and errors.

[ohai]

Now I try the new yard task. As I mentioned above, many documents for constants such as SDL2::Mixer::INIT_OGG are removed when I apply your changes.

I feel it is difficult to accept your PR as it is.

[furunkel]

Well, that makes absolutely no sense to my mind. Why would they disappear ?

I feel it is difficult to accept your PR as it is.

Nop, I can keep this in my fork.

[ohai]

Yard recognizes the following C code as the definition of SDL2::Mixer::INIT_OGG:

   /* Initialize Ogg vorbis loader */
  rb_define_const(mMixer, "INIT_OGG", UINT2NUM(MIX_INIT_OGG));

But yard does not recognize the following C code:

#define DEFINE_MIX_INIT(c) \
  rb_define_const(mMixer, "INIT_" #c, UINT2NUM(MIX_INIT_## c))
/* Initialize Ogg vorbis loader */
DEFINE_MIX_INIT(OGG);

because yard cannot understand the C macros.

This is because because your changes fail to handle the constant documentation and I use the m4 macros instead of C macros.

[furunkel]

Now I see. Too bad. I will revert this part and add the necessary m4 translation task, might take a day or two, though.

[ohai]

Good.

Comments for your PR:

• In your PR, different kinds of modifications are contained. Please create separated pull requests:
  • Addition of the dependency of new tools, such as rake-compiler
  • Change of the location of files
  • Removal of m4 macros
  • Other code modifications
• Now there is no unit test. I think "test" target is not required now.
• Your change drops the support of yard i18n. Documentation is important. I18n documentation is also important.

[furunkel]

Okay, the vexatious m4 files are back in place, there is just no way around them. Note that the C files are staged so that m4 becomes a mere development dependency. .m4 files are automatically translated before compilation. YARD documentation generation seems to work too. Can't do more than this.

You are, of course, free to change anything you don't like.

[furunkel]

I forgot using a separate feature branch, I'd like to do further changes in my master branch, so I'm going to close this now. Feel free to merge in the commits up to this.