Hi everybody,

I'm looking for the absolute minimal set of files in phobos i _need_ to run a full featured D application.
This means that I don't want to have any unneeded functionality in these files, only the framework to make the language complete.

For me, this would mean:
- Object and Interface base
- Type info
- Exception handling
- Startup system (ctor/dtor handling, __main, _main)

Only as stubs
- GC
- System interface
- Stdc lib
- Thread

Has someone an idea? Walter?

Lukas Lädrach wrote:
> Hi everybody,
> 
> I'm looking for the absolute minimal set of files in phobos i _need_ to run a full featured D application.
> This means that I don't want to have any unneeded functionality in these files, only the framework to make the language complete.
> 
> For me, this would mean:
> - Object and Interface base - Type info
> - Exception handling
> - Startup system (ctor/dtor handling, __main, _main)
> 
> Only as stubs
> - GC
> - System interface
> - Stdc lib
> - Thread
> 
> Has someone an idea? Walter?

Tango has this stuff separated; you may want to take a look at <http://www.dsource.org/projects/tango/browser/trunk>, especially lib/compiler/* (and lib/gc/stub/gc.d for malloc/free 'GC', easily modified if needed).
You'll probably also want at least part of lib/common/*. For example, Exception.d includes some error handler functions called by lib/compiler, and the definitions of the exception classes they throw.

I do think you missed a few items in your first list though. For example: associative arrays, dynamic casting, array concatenation, and 64-bit math on 32-bit systems all need runtime support in order to function properly.

Other than providing those as well, I think the only requirement this doesn't fit is that the Thread in lib/common/Thread.d isn't a stub. That should be easy enough to fix if you prefer a stub, though.

== Quote from Frits van Bommel (fvbommel@REMwOVExCAPSs.nl)'s article
> Lukas Lädrach wrote:
> > Hi everybody,
> >
> > I'm looking for the absolute minimal set of files in phobos i _need_ to run a full featured D application. This means that I don't want to have any unneeded functionality in these files, only the framework to make the
language complete.
> >
> > For me, this would mean:
> > - Object and Interface base
> > - Type info
> > - Exception handling
> > - Startup system (ctor/dtor handling, __main, _main)
> >
> > Only as stubs
> > - GC
> > - System interface
> > - Stdc lib
> > - Thread
> >
> > Has someone an idea? Walter?
> Tango has this stuff separated; you may want to take a look at
> <http://www.dsource.org/projects/tango/browser/trunk>, especially
> lib/compiler/* (and lib/gc/stub/gc.d for malloc/free 'GC', easily
> modified if needed).
> You'll probably also want at least part of lib/common/*. For example,
> Exception.d includes some error handler functions called by
> lib/compiler, and the definitions of the exception classes they throw.

The minimum you need to run a D application is basically what's in the
Tango runtime.  This is built as tango-base-dmd.lib for Win32 users
and libtango-base-dmd.a for Linux users (swap "dmd" for "gdc" if you're
using GDC).  As far as headers go, any .di header in the Tango user space
generally represents something in the runtime.  The principal components
include:

tango.core.Exception
tango.core.Memory
tango.core.Runtime
tango.core.Thread

Also, if you're on Win32, you'll find that tango-win32-dmd.lib is pulled in
as well.  This library backs what's in tango.sys.win32, and I believe it isn't
actually necessary for a bare-bones D application on Windows.  The choice
to hook things together this way occurred before we had a user-level
library, and I can't recall if it was purely for convenience or if there was a
functional reason for this decision as well (I think it was the former though).

If this is still too much baggage and/or you want to want to mess with the runtime itself, this is a good place to start:

http://www.dsource.org/projects/tango/wiki/TopicAdvancedConfiguration

that doc a bit out of date, but the concepts haven't changed, only the names of the libraries.  "phobos.lib" has been renamed to "tango-base-dmd.lib" for example.

If you're bent on using Phobos however, the division is far less clear.  You will
need everything in internal, plus std/typeinfo/*, std.thread, and a smattering
of other modules in std--basically any module that contains a function with
the prefix "extern (C) _d_..."  From memory, this includes std.asserterror,
std.moduleinit, and std.outofmemory, and a a few others.


Sean

Sean Kelly wrote:
> 
> If you're bent on using Phobos however, the division is far less clear.  You will
> need everything in internal, plus std/typeinfo/*, std.thread, and a smattering
> of other modules in std--basically any module that contains a function with
> the prefix "extern (C) _d_..."  From memory, this includes std.asserterror,
> std.moduleinit, and std.outofmemory, and a a few others.
> 
> 
> Sean

When I worked on Phobos for LLVMDC (a DMD based compiler project of mine), it was really frustrating how much of Phobos the core runtime library needed...

Just go with Tango and save yourself the hassle, it's much better structured, and inter-module-dependencies have actually been given some thought!

Tomas

Tomas Lindquist Olsen wrote:
> Sean Kelly wrote:
>>
>> If you're bent on using Phobos however, the division is far less clear.  You will
>> need everything in internal, plus std/typeinfo/*, std.thread, and a smattering
>> of other modules in std--basically any module that contains a function with
>> the prefix "extern (C) _d_..."  From memory, this includes std.asserterror,
>> std.moduleinit, and std.outofmemory, and a a few others.
>>
>>
>> Sean
> 
> When I worked on Phobos for LLVMDC (a DMD based compiler project of mine), it was really frustrating how much of Phobos the core runtime library needed...
> 
> Just go with Tango and save yourself the hassle, it's much better structured, and inter-module-dependencies have actually been given some thought!
> 
> Tomas

Is there anyway to perform object stripping so only accessed functions and structures are built into the final binary's?

Hans W. Uhlig wrote:
> Tomas Lindquist Olsen wrote:
>>
>> Just go with Tango and save yourself the hassle, it's much better structured, and inter-module-dependencies have actually been given some thought!
> 
> Is there anyway to perform object stripping so only accessed functions and structures are built into the final binary's?

At the moment, not really with DMD.
GDC inherits -ffunction-sections and -fdata-sections from GCC, those combined with -Wl,--gc-sections might work. I haven't tried this though, and I'm not aware of anyone that has.
IIRC --gc-sections breaks DMD exception handling so that doesn't really work there (--gc-sections will probably "work" with a custom linker script, but AFAICT then any function with an exception table (and anything it references) won't be stripped).

And of course, once LLVMDC (or another LLVM-based compiler) is complete enough I'm pretty sure it should be able to do that.