well, ive turned the DMEFE into a C library with a small D API wrapper. it works pretty nice. but since D doesnt support dynamic libraries Im not sure what you are saying. are you talking about a DMEFE DLL designed for use with something like C++? because until DDL gets its feet I dont see how dynamic libs are usefull in D


James Dunne wrote:
> Walter Bright wrote:
> 
>> "Kris" <fu@bar.com> wrote in message news:dhk4u9$29dt$1@digitaldaemon.com...
>>
>> [snip]
> 
>  >
> 
>>> It would also support the (more) rapid development of cross-referencing
>>> documentation, color-coded/linked source, and many other useful goodies.
>>>
>>> The hard part for a formatting/documentation tool is extracting relevant
>>> (i.e. marked up) content from the source code. Once that is done (by you),
>>> then the creativity and abundant talents of the community can be brought
>>
>>
>> to
>>
>>> bear on remaining tasks.
>>
>>
>>
>> My original goal for open sourcing the front end was so that people could
>> build ancilliary tools out of it. This has turned out to be a more daunting
>> task for third party tool developers than I'd anticipated.
>>
> 
> I've said this before, but right here feels like a great spot to reiterate: =P
> 
> To satisfy your original goal, it would be better to make the front-end a dynamic library with an exposed, simple, C API.  This would free third-party tool developers from the "daunting task" of dealing with the C++ classes and the headache of nicking out the back-end functions.  It would also allow third-party tool developers to write their tools in the D language, since it can easily interface with C functions/libraries. Some simple, well-defined set of good ol' C structs and C functions should do the trick.
> 
> DMDFE already exists for this purpose, I know, but what good is it if we have to rely on Ben Hinkle (or future maintainer) to consistently update it?  No offense to Ben, of course - he's doing a fantastic job and has lots of D-related projects going on.
> 
> BTW, it should be a dynamic library (DLL, SO) so as to use the host OS's native binary format to handle symbolic linking instead of dealing with static libs and the COFF vs. OMF incompatibilities.
> 
>>
>> [snip]
>>

JT wrote:
> well, ive turned the DMEFE into a C library with a small D API wrapper. it works pretty nice. but since D doesnt support dynamic libraries Im not sure what you are saying. are you talking about a DMEFE DLL designed for use with something like C++? because until DDL gets its feet I dont see how dynamic libs are usefull in D
> 
> 
> James Dunne wrote:
> 
>> Walter Bright wrote:
>>
>>> "Kris" <fu@bar.com> wrote in message news:dhk4u9$29dt$1@digitaldaemon.com...
>>>
>>> [snip]
>>
>>
>>  >
>>
>>>> It would also support the (more) rapid development of cross-referencing
>>>> documentation, color-coded/linked source, and many other useful goodies.
>>>>
>>>> The hard part for a formatting/documentation tool is extracting relevant
>>>> (i.e. marked up) content from the source code. Once that is done (by you),
>>>> then the creativity and abundant talents of the community can be brought
>>>
>>>
>>>
>>> to
>>>
>>>> bear on remaining tasks.
>>>
>>>
>>>
>>>
>>> My original goal for open sourcing the front end was so that people could
>>> build ancilliary tools out of it. This has turned out to be a more daunting
>>> task for third party tool developers than I'd anticipated.
>>>
>>
>> I've said this before, but right here feels like a great spot to reiterate: =P
>>
>> To satisfy your original goal, it would be better to make the front-end a dynamic library with an exposed, simple, C API.  This would free third-party tool developers from the "daunting task" of dealing with the C++ classes and the headache of nicking out the back-end functions.  It would also allow third-party tool developers to write their tools in the D language, since it can easily interface with C functions/libraries. Some simple, well-defined set of good ol' C structs and C functions should do the trick.
>>
>> DMDFE already exists for this purpose, I know, but what good is it if we have to rely on Ben Hinkle (or future maintainer) to consistently update it?  No offense to Ben, of course - he's doing a fantastic job and has lots of D-related projects going on.
>>
>> BTW, it should be a dynamic library (DLL, SO) so as to use the host OS's native binary format to handle symbolic linking instead of dealing with static libs and the COFF vs. OMF incompatibilities.
>>
>>>
>>> [snip]
>>>

I'm talking about doing exactly what you've done, but with equal emphasis on supporting other C/C++ programs in addition to D programs. I'd like to try out what you've done and see what all you've exposed through the C API.  Is your work available online somewhere?

Well, you are part correct with D's issues with DLLs: D does have issues with creating dynamic libraries in Linux, but not so much anymore with Win32.

Upon further thinking on the matter, doesn't Derelict project have Linux code to load up .so's?  I'm fairly certain it does via dlopen() and friends.  This shouldn't be too much of an issue to write a Derelict-like loader for the DMD front-end library (assuming it's done) in D.