How to make a generic DevKit

34 views
Skip to first unread message

Joe Duarte

unread,
Jul 17, 2016, 11:14:36 PM7/17/16
to RubyInstaller
Hi all,

What do I need to do to turn any MinGW install into DevKit?

Another way to phrase it: Can I replace the Ruby DevKit with any generic MinGW install? How do I do it?

The DevKit is a couple of years old, and specifically I'd like to use Stephan Lavavej's MinGW distro for all MinGW/gcc purposes, including DevKit. Since MinGW is pretty huge, I don't like having two or three MinGW installs on a machine. And as I mentioned, DevKit is using pretty old versions of gcc and such, and I really like Lavavej's bundles. (He's a senior Microsoft developer, a C++ guru, and works on Visual Studio's C++ compiler. An interesting recent post: https://blogs.msdn.microsoft.com/vcblog/2016/04/14/stl-fixes-in-vs-2015-update-2/)

Ancillary question: When exactly should we use --platform=ruby when installing gems? Always? Is it a safe default? I wouldn't know in advance whether any given gem needed gcc or other native compilation support.

Thanks,

Joe

Justin Baker

unread,
Jul 19, 2016, 3:47:39 PM7/19/16
to RubyInstaller
Hey Joe,


On Sunday, July 17, 2016 at 10:14:36 PM UTC-5, Joe Duarte wrote:
Hi all,

What do I need to do to turn any MinGW install into DevKit?

Another way to phrase it: Can I replace the Ruby DevKit with any generic MinGW install? How do I do it?

So I'll handle this in two parts. But I want to preface everything I say with I don't really know enough about the compiler toolchains, everything I say is from anecdotal experience of myself and what I've heard from others.

The first part is understanding that the Devkit is actually two parts, The first part is msys and the piecemeal tools that we need during the compile process, then the other part in mingw itself.


So to replace the compiler you would just need to make a new file/entry in the compilers folder.

The DevKit is a couple of years old, and specifically I'd like to use Stephan Lavavej's MinGW distro for all MinGW/gcc purposes, including DevKit. Since MinGW is pretty huge, I don't like having two or three MinGW installs on a machine. And as I mentioned, DevKit is using pretty old versions of gcc and such, and I really like Lavavej's bundles. (He's a senior Microsoft developer, a C++ guru, and works on Visual Studio's C++ compiler. An interesting recent post: https://blogs.msdn.microsoft.com/vcblog/2016/04/14/stl-fixes-in-vs-2015-update-2/)

Ancillary question: When exactly should we use --platform=ruby when installing gems? Always? Is it a safe default? I wouldn't know in advance whether any given gem needed gcc or other native compilation support.

So, here is why the DevKit isn't updated lightly. The `--platform=ruby` tag is basically saying, "Hey, give me the code I'll compile it all myself." Meaning you'll handle all the dependency management, and the compiler chain management.
Which brings us to... The compiler toolchains are interchangeable, except when they're not. I don't know enough to know when they are or aren't.

Also there are a couple of different libraries and tools that facilitate the ability for gem creators and maintainers to create versions of the gem compiled for Windows machines. They're all using the same version of the compiler toolchain(mingw) so we won't have weird segfaults. So it's kind of an ordeal to update it.

So, if you were to build your own Ruby using your own DevKit I would recommend ONLY using `--platform=ruby` if you want to be certain of no segfaults, but it means you need to handle all the library stuff yourself.

There's a lot more to it, but that's a quick gist of the DevKit and the problems, including my gaps in understanding, that have prevented me from upgrading the DevKit plus some info on how/when to use your own.
I kinda forgot what it was like to not be looking at this stuff and know what it is/does so feel free to ask more questions if I failed to explain it well.

Justin
Reply all
Reply to author
Forward
0 new messages