View mode: basic / threaded / horizontal-split · Log in · Help
November 16, 2007
Linking to libraries with D
Well I know this sounds a rather mundane question to all you code buffs out
there, but I'm wondering how I would use C libraries with D.

I've already somewhat figured it out, but I guess I'm still confused a little
because unlike C, D doesn't have header files, and unlike perl, D doesn't seem
to 'add' your imported modules into your code.

See, what I've done is I've converted the curl C headers to D, which leaves me
with two .d files. Now at first, with my perl experience I expected to be able
to just import the module, and the compiler would include the necessary
'header' code into the finished object. However this is not the case. I had to
compile the 'header' into an object, and then link it. This is all well and
good, but it feels.. rather 'unclean' I guess. I mean I expect I'll be using
curl for multiple applications, so am I going to have to make a static
library, just for my D applications to link to.. another library?

I guess the question I'm getting at is, would there a better way to do this?
Is there a way to make the compiler actually compile and include the code you
import? I would rather not have to make a static library just to use code I'm
importing from another library, but I also don't want to have to manually
build and link the code I'm importing every time either. Am I missing
something here?

Any advice much appreciated,
Jarrod.
November 16, 2007
Re: Linking to libraries with D
On Fri, 16 Nov 2007 12:28:33 +0000 (UTC)
Jarrod <gigantic.midget@gmail.com> wrote:

> Well I know this sounds a rather mundane question to all you code
> buffs out there, but I'm wondering how I would use C libraries with D.

Flattering. :P

> I guess the question I'm getting at is, would there a better way to
> do this? Is there a way to make the compiler actually compile and
> include the code you import? I would rather not have to make a static
> library just to use code I'm importing from another library, but I
> also don't want to have to manually build and link the code I'm
> importing every time either. Am I missing something here?

May I suggest taking a look at DSSS and/or Rebuild? It might do exactly
what you want.

-- 
Alexander Panek <alexander.panek@brainsware.org>
November 16, 2007
Re: Linking to libraries with D
Jarrod wrote:
> Well I know this sounds a rather mundane question to all you code buffs out
> there, but I'm wondering how I would use C libraries with D.
> 
> I've already somewhat figured it out, but I guess I'm still confused a little
> because unlike C, D doesn't have header files, and unlike perl, D doesn't seem
> to 'add' your imported modules into your code.
> 
> See, what I've done is I've converted the curl C headers to D, which leaves me
> with two .d files. Now at first, with my perl experience I expected to be able
> to just import the module, and the compiler would include the necessary
> 'header' code into the finished object. However this is not the case. I had to
> compile the 'header' into an object, and then link it. This is all well and
> good, but it feels.. rather 'unclean' I guess. I mean I expect I'll be using
> curl for multiple applications, so am I going to have to make a static
> library, just for my D applications to link to.. another library?
> 
> I guess the question I'm getting at is, would there a better way to do this?
> Is there a way to make the compiler actually compile and include the code you
> import? I would rather not have to make a static library just to use code I'm
> importing from another library, but I also don't want to have to manually
> build and link the code I'm importing every time either. Am I missing
> something here?
> 
> Any advice much appreciated,
> Jarrod.

If you've only translated the C headers to D, you need to link with the
actual C library too:

dmd yourapp.d curl.lib (or probably -L-lcurl on linux?)

The .d files work as both headers and implementation files, as needed.
If you have an app that contains two files, main.d and tools.d, and uses
the library stuff.lib, you compile and link like this:

dmd main.d tools.d stuff.lib

Lets assume that main.d imports tools.d.  When the compiler compiles
main.d, it uses tools.d just as a header, to see that the correct
declarations are there.  But unless you put it on the compiler's command
line, tools.d itself won't actually be compiled and linked.

You can use the bud tool from dsource.org/projects/build to automate
this.  Then you only need to include the main source file, plus
libraries to get the same effect:

bud main.d stuff.lib

There's also a similar tool called dsss that linux users seem to prefer:
http://www.dsource.org/projects/dsss
November 16, 2007
Re: Linking to libraries with D
== Quote from torhu
> Lets assume that main.d imports tools.d.  When the compiler compiles
> main.d, it uses tools.d just as a header, to see that the correct
> declarations are there.  But unless you put it on the compiler's command
> line, tools.d itself won't actually be compiled and linked.
So I thought. This is a tad disappointing, as I was hoping I could use the import
system as a means of actually including the code itself. I guess its not a huge
setback but it does sure feel a bit 'broken' to implement such a system. It would
seem more intuitive to have the imported modules.. well, imported, instead of just
used as a header.

> You can use the bud tool from dsource.org/projects/build to automate
> this.  Then you only need to include the main source file, plus
> libraries to get the same effect:
> bud main.d stuff.lib
> There's also a similar tool called dsss that linux users seem to prefer:
> http://www.dsource.org/projects/dsss
I have dsss, but I wasn't aware that it could be used to automate this process.
Alexanders reply also suggested dsss, so I guess I'll look into its usage.

Thanks to you both for the quick reply,
Jarrod.
November 16, 2007
Re: Linking to libraries with D
On Nov 16, 2007 1:28 PM, Jarrod <gigantic.midget@gmail.com> wrote:
> Well I know this sounds a rather mundane question to all you code buffs out
> there, but I'm wondering how I would use C libraries with D.

If you use DSSS, you could add this to your curl.d:

version(build) pragma(link, "curl");

This will work on both Windows and Linux. I'm not actually 100% sure
this is the proper "DSSS way", but it works for me.

Anders
November 16, 2007
Re: Linking to libraries with D
Jarrod wrote:
> I have dsss, but I wasn't aware that it could be used to automate this process.
> Alexanders reply also suggested dsss, so I guess I'll look into its usage.

To get started, just replace 'dmd' in your command line with 'rebuild', 
but leave out all .d files except the one with your main function in it. 
 Rebuild comes with dsss, and is what dsss uses for the actual 
building.  Later, you can have a look at what features dsss adds on top 
of rebuild.
November 16, 2007
Re: Linking to libraries with D
== Quote from Anders Bergh
> If you use DSSS, you could add this to your curl.d:
> version(build) pragma(link, "curl");
> This will work on both Windows and Linux. I'm not actually 100% sure
> this is the proper "DSSS way", but it works for me.
> Anders

Anders,
I think I worded the topic a bit wrong. My issue is not that I can't link with the
C library, it's more that I can't link with the C library without having to
compile curl.d.
I guess it just seems redundant to me that I have to compile what should only
really be a header file. And I'll be compiling it into a static library no less,
meaning I needed to make a library just to interface with another library.

Not exactly seamless.
Oh well, just a few more minutes of effort anyway.

Thanks for the reply,
Jarrod.
November 16, 2007
Re: Linking to libraries with D
== Quote from torhu
> To get started, just replace 'dmd' in your command line with 'rebuild',
> but leave out all .d files except the one with your main function in it.
>   Rebuild comes with dsss, and is what dsss uses for the actual
> building.  Later, you can have a look at what features dsss adds on top
> of rebuild.

Holy crap, it uses the power of black magic and just makes it all work.

Wow this tool is fantastic. Thanks a lot!
Jarrod.
November 16, 2007
Re: Linking to libraries with D
On Fri, 16 Nov 2007 13:33:17 +0000 (UTC)
Jarrod <gigantic.midget@gmail.com> wrote:

> > You can use the bud tool from dsource.org/projects/build to automate
> > this.  Then you only need to include the main source file, plus
> > libraries to get the same effect:
> > bud main.d stuff.lib
> > There's also a similar tool called dsss that linux users seem to
> > prefer: http://www.dsource.org/projects/dsss

> I have dsss, but I wasn't aware that it could be used to automate
> this process. Alexanders reply also suggested dsss, so I guess I'll
> look into its usage.

Well, that's one of the major reasons why Rebuild (and also bud) has
been created. :)

-- 
Alexander Panek <alexander.panek@brainsware.org>
November 16, 2007
Re: Linking to libraries with D
Jarrod wrote:
> == Quote from Anders Bergh
>> If you use DSSS, you could add this to your curl.d:
>> version(build) pragma(link, "curl");
>> This will work on both Windows and Linux. I'm not actually 100% sure
>> this is the proper "DSSS way", but it works for me.
>> Anders
> 
> Anders,
> I think I worded the topic a bit wrong. My issue is not that I can't link with the
> C library, it's more that I can't link with the C library without having to
> compile curl.d.
> I guess it just seems redundant to me that I have to compile what should only
> really be a header file. And I'll be compiling it into a static library no less,
> meaning I needed to make a library just to interface with another library.

Ever heard of "precompiled headers" in C++ land.  Do they give you the 
shivers just hearing the word?  They do me.  Because precompiled headers 
are an awful collection of vendor specific kludges to try to fix the 
terrible performance that comes from the C++ way of textually including 
every header file.  Because #include just pastes the text in, it means 
for every .c/.cpp file the compiler comes across it re-parses and 
re-compiles *all* the headers that that .c file depends on in any way.

Doing it the D way with modules means that every file only needs to be 
parsed and compiled once.  That's part of the reason why D complies so 
darn fast compared to C++.  It's like "precompiled headers" are always on.

> Not exactly seamless.
> Oh well, just a few more minutes of effort anyway.

Yes, well many folks have complained that bud or dsss-like functionality 
should be part of the compiler.  That is, dmd should have a way to 
recursively compile all imports included from the modules listed on the 
compile line.  For some reason Walter just doesn't go for it though.  I 
don't really know why.  A lot about D's module system seems to be 
inspired by how Java's modules work.  But javac does do recursive 
imports as far as I recall.  I remember it being one of Sun's marketing 
points originally: "With java you don't need makefiles!  'javac 
main.java' is all you need!"  Of course, after people got past writing 
little dancing duke applets they realized that a build tool *was* still 
needed, so now they have Ant, make redone in XML for some godawful reason.

So maybe I answered my own question.  Ant may be why Walter decided not 
to bother putting build-tool functionality into dmd.  Perhaps he felt 
people would inevitably be unsatisfied with whatever limited build tool 
functionality is built into the compiler.  So best just to keep the 
compiler lean and let external tools take care of it from the beginning.

Walter did add one feature to dmd to help writers of such tool, though. 
 "dmd -v main.d"  will list all the imports required by main in an 
easy-to-parse format.

--bb
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home