On 9 May 2013 13:06, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 9 May 2013 12:50, David Nadlinger <see@klickverbot.at> wrote:
>
>> On Thursday, 9 May 2013 at 09:11:05 UTC, Thomas Koch wrote:
>>
>>> There are languages in Debian that rely on themselves to be build and
>>> it's a
>>> headache to support those languages on all architectures.
>>>
>>
>> Wouldn't the "normal" workflow for porting to a new platform be to start out with a cross-compiler anyway?
>>
>> David
>>
>
> Currently... only if the target platform does not have a native c++ compiler.
>
>
Though that assumes that the target platform has a c compiler already though... :)

-- 
Iain Buclaw

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

On May 5, 2013 2:36 PM, "Iain Buclaw" <ibuclaw@gdcproject.org> wrote:
>
> Daniel and/or David,
>
> We should list down in writing the issues preventing DMD, GDC, and LDC
having a shared code base.  From what David has shown me, LDC will need the most work for this, but I'll list down what I can remember.
>
> 1. Support extern(C++) classes so can have a split C++/D implementation
of eg: Expression and others.
>
> 2. Support representing integers and floats to a greater precision than
what the host can natively support. In D there's BigInt for integral types, and there's a possibility of using std.numeric for floats.  For me, painless conversion between eg: BigInt <-> GCC's double_int is a requirement, but that is more of an after thought at this point in time.
>

Actually, the more I sit down and think about it, the more I question whether or not it is a good idea for the D D front end to have a dependency on phobos.   Maybe I should stop thinking in general.  :)

Regards
-- 
Iain Buclaw

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

"Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:mailman.1201.1368284962.4724.digitalmars-d@puremagic.com...
>
> Actually, the more I sit down and think about it, the more I question
> whether or not it is a good idea for the D D front end to have a
> dependency
> on phobos.   Maybe I should stop thinking in general.  :)
>

Yeah, the compiler can't depend on phobos.  But if we really need to, we can clone a chunk of phobos and add it to the compiler.  Just so long as there isn't a loop.  BigInt is a pretty good candidate.

On Saturday, 11 May 2013 at 15:16:29 UTC, Daniel Murphy wrote:
> "Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message
> news:mailman.1201.1368284962.4724.digitalmars-d@puremagic.com...
>>
>> Actually, the more I sit down and think about it, the more I question
>> whether or not it is a good idea for the D D front end to have a dependency
>> on phobos.   Maybe I should stop thinking in general.  :)
>>
>
> Yeah, the compiler can't depend on phobos.

Why?

If we keep a "must compile with several past versions" policy anyway, what would make Phobos special?

David

On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger wrote:
> On Saturday, 11 May 2013 at 15:16:29 UTC, Daniel Murphy wrote:
>> "Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message
>> news:mailman.1201.1368284962.4724.digitalmars-d@puremagic.com...
>>>
>>> Actually, the more I sit down and think about it, the more I question
>>> whether or not it is a good idea for the D D front end to have a dependency
>>> on phobos.   Maybe I should stop thinking in general.  :)
>>>
>>
>> Yeah, the compiler can't depend on phobos.
>
> Why?
>
> If we keep a "must compile with several past versions" policy anyway, what would make Phobos special?
>
> David

It prevent the use of newer feature of D in phobos.

On Saturday, 11 May 2013 at 16:08:02 UTC, deadalnix wrote:
> On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger wrote:
>> If we keep a "must compile with several past versions" policy anyway, what would make Phobos special?
>>
>> David
>
> It prevent the use of newer feature of D in phobos.

?!

It prevents the use of newer Phobos features in the compiler, but we would obviously use the Phobos version that comes with the host D compiler to compile the frontend, not the version shipping with the frontend.

Maybe I'm missing something obvious, but I really can't see the issue here.

David

On Saturday, 11 May 2013 at 16:15:13 UTC, David Nadlinger wrote:
> On Saturday, 11 May 2013 at 16:08:02 UTC, deadalnix wrote:
>> On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger wrote:
>>> If we keep a "must compile with several past versions" policy anyway, what would make Phobos special?
>>>
>>> David
>>
>> It prevent the use of newer feature of D in phobos.
>
> ?!
>
> It prevents the use of newer Phobos features in the compiler, but we would obviously use the Phobos version that comes with the host D compiler to compile the frontend, not the version shipping with the frontend.
>
> Maybe I'm missing something obvious, but I really can't see the issue here.
>
> David

No, that is what have been said : you got to fork phobos and ship your own with the compiler.

On Saturday, 11 May 2013 at 16:27:37 UTC, deadalnix wrote:
> On Saturday, 11 May 2013 at 16:15:13 UTC, David Nadlinger wrote:
>> On Saturday, 11 May 2013 at 16:08:02 UTC, deadalnix wrote:
>>> On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger wrote:
>>>> If we keep a "must compile with several past versions" policy anyway, what would make Phobos special?
>>>>
>>>> David
>>>
>>> It prevent the use of newer feature of D in phobos.
>>
>> ?!
>>
>> It prevents the use of newer Phobos features in the compiler, but we would obviously use the Phobos version that comes with the host D compiler to compile the frontend, not the version shipping with the frontend.
>>
>> Maybe I'm missing something obvious, but I really can't see the issue here.
>>
>> David
>
> No, that is what have been said : you got to fork phobos and ship your own with the compiler.

I still don't get what your point is.

To build any D application (which might be a D compiler or not), you need a D compiler on your host system. This D compiler will come with druntime, Phobos and any number of other libraries installed.

Now, if the application you are building using that host compiler is DMD, you will likely use that new DMD to build a (newer) version of druntime and Phobos later on. But this doesn't have anything to do with what libraries of the host system the application can or can't use.

No fork in sight anywhere.

David

"David Nadlinger" <see@klickverbot.at> wrote in message news:llovknbpvcnksinsnpfk@forum.dlang.org...
> On Saturday, 11 May 2013 at 15:16:29 UTC, Daniel Murphy wrote:
>> "Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:mailman.1201.1368284962.4724.digitalmars-d@puremagic.com...
>>>
>>> Actually, the more I sit down and think about it, the more I question
>>> whether or not it is a good idea for the D D front end to have a
>>> dependency
>>> on phobos.   Maybe I should stop thinking in general.  :)
>>>
>>
>> Yeah, the compiler can't depend on phobos.
>
> Why?
>
> If we keep a "must compile with several past versions" policy anyway, what would make Phobos special?
>
> David

Yes it's possible, but it seems like a really bad idea because:
- Phobos is huge
- Changes in phobos now have the potential to break the compiler

If you decide that all later versions of the compiler must compile with all earlier versions of phobos, then those phobos modules are unable to change.

If you do it the other way and say old versions of the compiler must be able to compile the newer compilers and their versions of phobos, you've locked phobos to an old subset of D.  (And effectively made the compiler source base enormous)

The nice middle ground is you take the chunk of phobos you need, add it to the compiler source, and say 'this must always compile with earlier versions of the compiler'.

On Saturday, 11 May 2013 at 17:10:51 UTC, Daniel Murphy wrote:
> If you decide that all later versions of the compiler must compile with all
> earlier versions of phobos, then those phobos modules are unable to change.

In (the rare) case of breaking changes, we could always work around them in the compiler source (depending on __VERSION__), rather than duplicating everything up-front.

I believe *this* is the nice middle ground.

David