modest proposal for enhanced multi-platform support

[jonforums]

It's likely that platform specific implementation details will become scattered throughout the codebase making it less maintainable and less understandable.

I propose a change to the current include structure to better modularize platform specifics where possible. Specifically, update mruby.h with the following

...
#ifndef MRUBY_H
#define MRUBY_H

#include 
#include "mrbconf.h"

#if defined(__unix__) || defined(__POSIX__) || defined(__APPLE__)
# /* TODO: include "mrb-internal/mrb-unix.h" */
#else
# include "mrb-internal/mrb-win.h"
#endif

and start by consolidating all the applicable windows impl oddities into the include/mrb-internal/mrb-win.h file. The goal is to minimize platform specific #ifdef's in the *.c files and allow for future platform specific include files, eg. mrb-internal/mrb-arm.h.

An example of how this looks in real-world code:

• https://github.com/joyent/libuv/blob/master/include/uv.h#L66-70
• https://github.com/joyent/libuv/blob/master/include/uv-private/uv-win.h#L156-167
• https://github.com/joyent/libuv/blob/master/include/uv-private/uv-unix.h#L46-59

[matz]

The mruby core part should be implemented in (C99 - VC unsupported features) in principle, so we shouldn't need such platform specific headers. Time (for gettimeofday and gmtime_r) is exceptional, since C99 is far from complete here.

[jonforums]

The benefit of enabling platform specific code organization really starts to shine when you're implementing portability via API abstraction. Of course the cost to this style is that the build system has to be made smarter. But non-build system developers/contributors (the majority) don't have to pay that cost to get the code organization benefits.

For example, say you'd like to implement cross platform function loading from shared libs via an API wrapper.

One style is the libuv style in which you use a platform specific header and platform specific source files:

• unix: https://github.com/joyent/libuv/blob/master/src/unix/dl.c
• windows: https://github.com/joyent/libuv/blob/master/src/win/dl.c

Another style is the current lua style in which you #define\if defined the different platform specific API wrapper impl functions all in the same source file: http://www.lua.org/source/5.2/loadlib.c.html

And a related style is the current ruby plugin for vim style in which you rewrite the symbol name with a #ifdef\#define and try to use the same impl code in a single file:

• http://code.google.com/p/vim/source/browse/src/if_ruby.c#55
• http://code.google.com/p/vim/source/browse/src/if_ruby.c#466

Of those three styles, I find libuv's cleaner, smaller source files with minimal #ifdef to be more focused, more understandable, and more maintainable. Smaller, more focused source files tend to be kept fresh and updated because their complexity is less. For example, once a file grows in size and complexity similar to CRuby's file.c developers/contributors tend not refactor it because of (a) the fear of breaking things, and (b) it's sheer size makes it harder to reason about.

mruby source may never have to deal with this file size/complexity issue, but then again it may as devs try using mruby on a number of different platforms.

[matz]

As a original implementer of I understand what you mean. We've tried so much to hide platform variety.
But the goal of mruby is to provide platform neutral implementation, except for a few corner cases,e.g. gettimeofday in time.c Platform dependent code, such as I/O, Sockets, etc. should be implemented outside of the core.

So my opinion is that mruby will not need such mechanism to hide the detail. On the other hand, the platform dependent extensions to mruby may use a tool such as autotool.

[jonforums]

OK, thanks for more info on mruby's goals wrt platform dependent code.

And I really hope extensions don't use autotools as it unnecessarily complicates multi platform support. As you can guess, I think it's a poor choice vs. cmake...it should be banned from mruby ;)

Please close this issue so it doesn't attract bikeshedding and distract from implementation.

[matz]

Yes, and I hope cmake will make us happy.