Thread overview
object.di error
Feb 10, 2012
Johannes Pfau
Feb 10, 2012
Iain Buclaw
Feb 10, 2012
Johannes Pfau
Feb 13, 2012
Johannes Pfau
Feb 13, 2012
Iain Buclaw
February 10, 2012
When trying to add a --disable-libphobos switch to GCC I saw that GCC already has code that makes it possible to --disable any target library, although I think this is not documented in the configure --help output.

Anyway, this means configure --disable-libphobos works fine and builds a gdc without phobos. Obviously object.di isn't installed then and this error pops up when trying to compile something:

object.d: Error: module object is in file 'object.d' which cannot be read

However, for C-like code a completely empty object.di works fine, so could we disable the object.di detection when -nostdlib or -nophoboslib is passed, or at least make it a warning instead of an error?

Or add a new switch to ignore a missing object.di? It just doesn't seem to make sense, that object.di must be there, but can be completely empty.
February 10, 2012
On 10 February 2012 10:36, Johannes Pfau <nospam@example.com> wrote:
> When trying to add a --disable-libphobos switch to GCC I saw that GCC already has code that makes it possible to --disable any target library, although I think this is not documented in the configure --help output.
>
> Anyway, this means configure --disable-libphobos works fine and builds a gdc without phobos. Obviously object.di isn't installed then and this error pops up when trying to compile something:
>
> object.d: Error: module object is in file 'object.d' which cannot be read
>
> However, for C-like code a completely empty object.di works fine, so could we disable the object.di detection when -nostdlib or -nophoboslib is passed, or at least make it a warning instead of an error?
>
> Or add a new switch to ignore a missing object.di? It just doesn't seem to make sense, that object.di must be there, but can be completely empty.

object.[d, di] is special to the compiler, I think it would be best to _always_ ship it, or have it separate from being directly under the usual /usr/include directories for the standard library.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
February 10, 2012
Am Fri, 10 Feb 2012 14:12:11 +0000
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:

> On 10 February 2012 10:36, Johannes Pfau <nospam@example.com> wrote:
> > When trying to add a --disable-libphobos switch to GCC I saw that GCC already has code that makes it possible to --disable any target library, although I think this is not documented in the configure --help output.
> >
> > Anyway, this means configure --disable-libphobos works fine and builds a gdc without phobos. Obviously object.di isn't installed then and this error pops up when trying to compile something:
> >
> > object.d: Error: module object is in file 'object.d' which cannot be read
> >
> > However, for C-like code a completely empty object.di works fine, so could we disable the object.di detection when -nostdlib or -nophoboslib is passed, or at least make it a warning instead of an error?
> >
> > Or add a new switch to ignore a missing object.di? It just doesn't seem to make sense, that object.di must be there, but can be completely empty.
> 
> object.[d, di] is special to the compiler, I think it would be best to _always_ ship it, or have it separate from being directly under the usual /usr/include directories for the standard library.
> 

Yep, anything 'class' related won't work without object.di and probably much more. But to make a app using those features link, object_.d needs to be compiled in as well, and that pulls in some druntime dependencies (not too many), so to ship a minimal working object.di we'd also have to ship a minimal 'runtime' library. I'm not sure what's the right decision here, but it'd be great if could make a minimal compiler work for C-like code with minimal dependencies (one object.di file shipped by default definitely counts as minimal dependencies though).
February 13, 2012
Am Fri, 10 Feb 2012 19:36:22 +0100
schrieb Johannes Pfau <nospam@example.com>:

> Yep, anything 'class' related won't work without object.di and probably much more. But to make a app using those features link, object_.d needs to be compiled in as well, and that pulls in some druntime dependencies (not too many), so to ship a minimal working object.di we'd also have to ship a minimal 'runtime' library. I'm not sure what's the right decision here, but it'd be great if could make a minimal compiler work for C-like code with minimal dependencies (one object.di file shipped by default definitely counts as minimal dependencies though).

I guess we should just keep everything as it is. A minimal runtime seems too much effort right now and for testing very basic functionality it's always possible to create an empty object.di.
February 13, 2012
On 13 February 2012 17:55, Johannes Pfau <nospam@example.com> wrote:
> Am Fri, 10 Feb 2012 19:36:22 +0100
> schrieb Johannes Pfau <nospam@example.com>:
>
>> Yep, anything 'class' related won't work without object.di and probably much more. But to make a app using those features link, object_.d needs to be compiled in as well, and that pulls in some druntime dependencies (not too many), so to ship a minimal working object.di we'd also have to ship a minimal 'runtime' library. I'm not sure what's the right decision here, but it'd be great if could make a minimal compiler work for C-like code with minimal dependencies (one object.di file shipped by default definitely counts as minimal dependencies though).
>
> I guess we should just keep everything as it is. A minimal runtime seems too much effort right now and for testing very basic functionality it's always possible to create an empty object.di.

I think --disable-libphobos would go hand in hand with some sort of --default-gdc-lib=FOO.  FOO being the default library the driver attempts to link to.   This would be for people who have their own substitute for libphobos, be it a mini druntime, tango, or other bespoke library.

However the constant should always be that object.di is always shipped, and the compiler *always* depends on that.


Regards

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';