When will D be able to compile the same source to a .dll on windows and a .so on Linux?

Thanks,

-Craig

Craig Black wrote:
> When will D be able to compile the same source to a .dll on windows and a .so on Linux?


ddl may resolve this

"kris" <foo@bar.com> wrote in message news:e624e1$du6$1@digitaldaemon.com...
> Craig Black wrote:
>> When will D be able to compile the same source to a .dll on windows and a .so on Linux?
>
>
> ddl may resolve this

Yeah, I guess what I should be asking is, When will DDL 1.0 be available?

-Craig

Craig Black wrote:

> 
> "kris" <foo@bar.com> wrote in message news:e624e1$du6$1@digitaldaemon.com...
>> Craig Black wrote:
>>> When will D be able to compile the same source to a .dll on windows and a .so on Linux?
>>
>>
>> ddl may resolve this
> 
> Yeah, I guess what I should be asking is, When will DDL 1.0 be available?
> 
> -Craig

When it's done ;) Anyway, it's not a very high probability for ELF support being in there. You can follow the progress in the forum at DSource, or at the Trac page. http://www.dsource.org/projects/ddl

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

In article <e6262v$h39$1@digitaldaemon.com>, Craig Black says...
>
>
>"kris" <foo@bar.com> wrote in message news:e624e1$du6$1@digitaldaemon.com...
>> Craig Black wrote:
>>> When will D be able to compile the same source to a .dll on windows and a .so on Linux?
>>
>>
>> ddl may resolve this
>
>Yeah, I guess what I should be asking is, When will DDL 1.0 be available?

Well, Lars said it best.

The only thing that's keeping an official 1.0 release off the table has been the documentation and the remaining kinks in the OMF loader - I will be applying a new bugfix later tonight.  By far and large, DDL is already here and in a usable state.

- EricAnderton at yahoo

In article <e624e1$du6$1@digitaldaemon.com>, kris says...
>
>Craig Black wrote:
>> When will D be able to compile the same source to a .dll on windows and a .so on Linux?
>
>
>ddl may resolve this

Possibly.

The trick here is that Walter has ruled out the possibility of 100% binary compatibility so using DDL 1.0 as a compile-once* solution is a no-go.  But should Craig need something that fits the use-case of a dll/so, as a complete D-built dynamic lib, then DDL should work nicely.


* - Some food for thought here: As the ABI below the D compiler level is concerned, DMD backs DMC and GDC backs GCC where exception handling and real-width (80/100bit) are concerned.  This is a good thing as far as linking with 'native' dynamic and static libs go.  While all this puts the current toolset out of the running, it doesn't exclude the possibility of producing completely cross-platform binary solution, at the cost of legacy binary compatibility.  It would just require a custom compiler that backs a stricter ABI (maybe by the time we land on the moon again).

- EricAnderton at yahoo

pragma wrote:
> In article <e624e1$du6$1@digitaldaemon.com>, kris says...
> 
>>Craig Black wrote:
>>
>>>When will D be able to compile the same source to a .dll on windows and a .so on Linux?
>>
>>
>>ddl may resolve this
> 
> 
> Possibly.
> 
> The trick here is that Walter has ruled out the possibility of 100% binary
> compatibility so using DDL 1.0 as a compile-once* solution is a no-go.  But
> should Craig need something that fits the use-case of a dll/so, as a complete
> D-built dynamic lib, then DDL should work nicely.
> 
> 
> * - Some food for thought here: As the ABI below the D compiler level is
> concerned, DMD backs DMC and GDC backs GCC where exception handling and
> real-width (80/100bit) are concerned.  This is a good thing as far as linking
> with 'native' dynamic and static libs go.  While all this puts the current
> toolset out of the running, it doesn't exclude the possibility of producing
> completely cross-platform binary solution, at the cost of legacy binary
> compatibility.  It would just require a custom compiler that backs a stricter
> ABI (maybe by the time we land on the moon again).
> 
> - EricAnderton at yahoo


Perhaps cross-platform binaries might come in useful for those who need to hide the implementation. But for the rest of us, just having a single source base that operates on both (without the need to master the underlying relevant ddl/so mechanics) will be awesome! I suspect it's the latter that Craig was getting at?

"kris" <foo@bar.com> wrote in message news:e62loh$18ot$1@digitaldaemon.com...
> pragma wrote:
>> In article <e624e1$du6$1@digitaldaemon.com>, kris says...
>>
>>>Craig Black wrote:
>>>
>>>>When will D be able to compile the same source to a .dll on windows and a .so on Linux?
>>>
>>>
>>>ddl may resolve this
>>
>>
>> Possibly.
>>
>> The trick here is that Walter has ruled out the possibility of 100%
>> binary
>> compatibility so using DDL 1.0 as a compile-once* solution is a no-go.
>> But
>> should Craig need something that fits the use-case of a dll/so, as a
>> complete
>> D-built dynamic lib, then DDL should work nicely.

Compile-once would be very cool, but it is not necessary for my purposes, so I suppose DDL will solve my problems.  I also hear DDL provides run-time reflection.  I am very interested in this feature.  How does it do this? What is the API look like?

>> * - Some food for thought here: As the ABI below the D compiler level is
>> concerned, DMD backs DMC and GDC backs GCC where exception handling and
>> real-width (80/100bit) are concerned.  This is a good thing as far as
>> linking
>> with 'native' dynamic and static libs go.  While all this puts the
>> current
>> toolset out of the running, it doesn't exclude the possibility of
>> producing
>> completely cross-platform binary solution, at the cost of legacy binary
>> compatibility.  It would just require a custom compiler that backs a
>> stricter
>> ABI (maybe by the time we land on the moon again).
>>
>> - EricAnderton at yahoo
>
>
> Perhaps cross-platform binaries might come in useful for those who need to hide the implementation. But for the rest of us, just having a single source base that operates on both (without the need to master the underlying relevant ddl/so mechanics) will be awesome! I suspect it's the latter that Craig was getting at?

Yes.  And much thanks to you and all the other contributors that have made DDL a possibility.  If it is what I understand it is, I am somewhat in awe that you have been able to pull it off.

-Craig

In article <e64858$mr3$1@digitaldaemon.com>, Craig Black says...
>
>Compile-once would be very cool, but it is not necessary for my purposes, so I suppose DDL will solve my problems.  I also hear DDL provides run-time reflection.  I am very interested in this feature.  How does it do this? What is the API look like?

It doesn't do reflection per-se, but it provides the underpinnings to build a runtime reflection system (sans attributes, codegen and AOP of course). In a nutshell, DDL exposes a generic interface for accessing the runtime symbol information for *everything* within the current D executable.  If the linker can see it, DDL can see it.  All a formal reflection API needs is to intellegently demangle and process this symbol info on demand.

At present, DDL does provide some rudimentary reflection via templates for the purposes of binding functions and fields out of loaded binaries - but that's about it.  This is about as reflective as DLL or .so files, give or take a bit.


>> Perhaps cross-platform binaries might come in useful for those who need to hide the implementation. But for the rest of us, just having a single source base that operates on both (without the need to master the underlying relevant ddl/so mechanics) will be awesome! I suspect it's the latter that Craig was getting at?
>
>Yes.  And much thanks to you and all the other contributors that have made DDL a possibility.  If it is what I understand it is, I am somewhat in awe that you have been able to pull it off.

Thank you, but don't count yer chickens yet. ;)

It does work as-is, but there's some considerable work to be done.  Right now, communal data records* are kicking my butt and threating a minor API change - it seems I'm still learning the corner-cases of the OMF.  That aside, I am completely confident in the theory behind DDL and what it will do when complete.

- EricAnderton at yahoo

"pragma" <pragma_member@pathlink.com> wrote in message news:e64dot$u1q$1@digitaldaemon.com...
> In article <e64858$mr3$1@digitaldaemon.com>, Craig Black says...
>>
>>Compile-once would be very cool, but it is not necessary for my purposes,
>>so
>>I suppose DDL will solve my problems.  I also hear DDL provides run-time
>>reflection.  I am very interested in this feature.  How does it do this?
>>What is the API look like?
>
> It doesn't do reflection per-se, but it provides the underpinnings to
> build a
> runtime reflection system (sans attributes, codegen and AOP of course). In
> a
> nutshell, DDL exposes a generic interface for accessing the runtime symbol
> information for *everything* within the current D executable.  If the
> linker can
> see it, DDL can see it.  All a formal reflection API needs is to
> intellegently
> demangle and process this symbol info on demand.
>
> At present, DDL does provide some rudimentary reflection via templates for
> the
> purposes of binding functions and fields out of loaded binaries - but
> that's
> about it.  This is about as reflective as DLL or .so files, give or take a
> bit.

So is it possible to traverse all methods of a given class?  What about fields?

>>> Perhaps cross-platform binaries might come in useful for those who need
>>> to
>>> hide the implementation. But for the rest of us, just having a single
>>> source base that operates on both (without the need to master the
>>> underlying relevant ddl/so mechanics) will be awesome! I suspect it's
>>> the
>>> latter that Craig was getting at?
>>
>>Yes.  And much thanks to you and all the other contributors that have made DDL a possibility.  If it is what I understand it is, I am somewhat in awe that you have been able to pull it off.
>
> Thank you, but don't count yer chickens yet. ;)
>
> It does work as-is, but there's some considerable work to be done.  Right
> now,
> communal data records* are kicking my butt and threating a minor API
> change - it
> seems I'm still learning the corner-cases of the OMF.  That aside, I am
> completely confident in the theory behind DDL and what it will do when
> complete.
>
> - EricAnderton at yahoo

I am looking forward to the official 1.0 release.

-Craig