View mode: basic / threaded / horizontal-split · Log in · Help
December 21, 2005
External Library frustrations.
I know a big part of D's appeal is the whole "symbolic import" thing. The
problem I'm running into is that 
you can't symbolically include a lib file. You have to write up a whole other D
file to declare the functions 
in the library. This is kind of a pain in the ass, to put it bluntly, as if you
want to distribute a closed source 
library programmed in D, then you have to basically maintain two complete sets
of function declarations.

Which totally kills the appeal of D's symbolic imports. Is there any way at all
around this? Or is the 
symbolic import thing explicitly tied to files/paths, with no way around it?

daerid@gmail.com
December 21, 2005
Re: External Library frustrations.
daerid wrote:

> Which totally kills the appeal of D's symbolic imports. Is there any way at all
> around this? Or is the 
> symbolic import thing explicitly tied to files/paths, with no way around it?

Sounds like D could use another tool (besides the one already needed for 
making D import modules from C headers), for converting D implementation 
modules to D import modules. So you'd only have to maintain the source ?

I think basically it would be something like "s/\{.*?\}/;/g", but it'd 
need some more finesse to separate between structs and functions, etc.
Don't think you ever can escape from having an import module, though ?


Then again there were some improvements with D demangling lately, so...
So in the future it *might* be possible to create this from the objects.

Totally with you on the pain part, both going "in" to D and going "out".
On really rainy days, I don't think the C preprocessor was all that bad.

--anders

PS. Terminology used ("import module", etc.) explained in posting:
    http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15626
December 21, 2005
Re: External Library frustrations.
Have you checked DMD 0.141?
It has a -H flag to generated socalled 'header' files from sources.
Maybe it can help you.

Tamás Nagy

In article <dob9sp$1b61$1@digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>daerid wrote:
>
>> Which totally kills the appeal of D's symbolic imports. Is there any way at all
>> around this? Or is the 
>> symbolic import thing explicitly tied to files/paths, with no way around it?
>
>Sounds like D could use another tool (besides the one already needed for 
>making D import modules from C headers), for converting D implementation 
>modules to D import modules. So you'd only have to maintain the source ?
>
>I think basically it would be something like "s/\{.*?\}/;/g", but it'd 
>need some more finesse to separate between structs and functions, etc.
>Don't think you ever can escape from having an import module, though ?
>
>
>Then again there were some improvements with D demangling lately, so...
>So in the future it *might* be possible to create this from the objects.
>
>Totally with you on the pain part, both going "in" to D and going "out".
>On really rainy days, I don't think the C preprocessor was all that bad.
>
>--anders
>
>PS. Terminology used ("import module", etc.) explained in posting:
>     http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15626
December 21, 2005
Re: External Library frustrations.
MicroWizard wrote:

> Have you checked DMD 0.141?

Nope, still at DMD 0.140 here

> It has a -H flag to generated socalled 'header' files from sources.
> Maybe it can help you.

Will definitely check it out...

--anders


PS. I think the wording "header" is unfortunate, though,
and prefer the alternative term "import module" myself.
December 21, 2005
Re: External Library frustrations.
When Walter released dmd .141, he wrote

"3) This incorporates a new 'header' generator capability, written by Dave
Fladebo. I goofed it up merging it in, so it is disabled at the moment (just
the source for it is included). I hope to get it working by the next 
update."


MicroWizard wrote:
> Have you checked DMD 0.141?
> It has a -H flag to generated socalled 'header' files from sources.
> Maybe it can help you.
> 
> Tamás Nagy
> 
> In article <dob9sp$1b61$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
> 
>>daerid wrote:
>>
>>
>>>Which totally kills the appeal of D's symbolic imports. Is there any way at all
>>>around this? Or is the 
>>>symbolic import thing explicitly tied to files/paths, with no way around it?
>>
>>Sounds like D could use another tool (besides the one already needed for 
>>making D import modules from C headers), for converting D implementation 
>>modules to D import modules. So you'd only have to maintain the source ?
>>
>>I think basically it would be something like "s/\{.*?\}/;/g", but it'd 
>>need some more finesse to separate between structs and functions, etc.
>>Don't think you ever can escape from having an import module, though ?
>>
>>
>>Then again there were some improvements with D demangling lately, so...
>>So in the future it *might* be possible to create this from the objects.
>>
>>Totally with you on the pain part, both going "in" to D and going "out".
>>On really rainy days, I don't think the C preprocessor was all that bad.
>>
>>--anders
>>
>>PS. Terminology used ("import module", etc.) explained in posting:
>>    http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15626
> 
> 
>
Top | Discussion index | About this forum | D home