On 3 December 2017 at 13:20, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 12/3/2017 2:32 AM, Iain Buclaw wrote: >> >> People have been making alternative druntime libraries for a while >> now, either as stubs inside their own project, or by using minilibd. >> There's nothing stopping you from simply swapping out druntime for >> another implementation. > > > It may indeed work to use a special druntime. My expectation, however, is > that it's a lot more work trying to develop and support another runtime > library, and a lot more work for the user trying to get that library worked > into his build system. This will drastically cut down on the number of users > willing to give it a try. > > (Consider the ENDLESS problems Win64 users have trying to link in the VC C > runtime library, something that should be trivial. And these are experienced > VC developers.) > > Meanwhile, we've got -betterC today, and it's simple and it works.
I prefer the approach of, try compiling a simple "hello world" with an empty object.d file. Then inspect what the compiler does. Does it error and exit, or does it ICE? What can be done to prevent that from happening? When you reach the point that there's no way but to declare a symbol or function, add that to object.d and then move onto the next error or ICE. Repeat until you can compile and link your program. Next, try something a little more complex, such as define a struct and use it. Then again address all problems that you encounter with that. What you end up with, should be a compiler that is less coupled to the existence of object.d and all its definitions than what it was before. Doing things this way in a bottom-up fashion has allowed people to use gdc to target STM micro controllers.