www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - External Library frustrations.

reply daerid <daerid gmail.com> writes:
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
Dec 21 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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: digitalmars.D/15626
Dec 21 2005
parent reply MicroWizard <MicroWizard_member pathlink.com> writes:
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: digitalmars.D/15626

Dec 21 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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.
Dec 21 2005
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
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: digitalmars.D/15626


Dec 21 2005