www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Automatically linking imports

reply Nils Hensel <nils.hensel web.de> writes:
Hi,

I was wondering why imported modules are not automatically linked. As I 
have been tinkering mostly with Python in the last few years I expected 
an imported module to be usable right away.

Let's say I have a module called mymodule which contains some data and I 
write in example.d:

   import mymodule;

and compile it like

   dmd example.d

I get

   Error 42: Symbol Undefined IMAGINE_NAME_OF_DATA_HERE

unless I state that mymodule.[d|obj] shall be compiled/linked as well.

Isn't it completely obvious from the import statement that I intend to 
use it? Why does it have to be explicitly declared?

Regards,
Nils
Apr 24 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 24 Apr 2005 13:03:45 +0200, Nils Hensel wrote:

 Hi,
 
 I was wondering why imported modules are not automatically linked. As I 
 have been tinkering mostly with Python in the last few years I expected 
 an imported module to be usable right away.
 
 Let's say I have a module called mymodule which contains some data and I 
 write in example.d:
 
    import mymodule;
 
 and compile it like
 
    dmd example.d
 
 I get
 
    Error 42: Symbol Undefined IMAGINE_NAME_OF_DATA_HERE
 
 unless I state that mymodule.[d|obj] shall be compiled/linked as well.
 
 Isn't it completely obvious from the import statement that I intend to 
 use it? Why does it have to be explicitly declared?

I don't know the answer to that, however I wrote a utility that analyzes your application's source code files and sort of creates an on-the-fly command line for you. It then compiles only those sources that need to be made up to date, and places all the right objects onto the command line for you. You can find out more at http://www.dsource.org/projects/build Typically you would type in ... build example to compile and link your code. -- Derek Parnell Melbourne, Australia 24/04/2005 9:12:36 PM
Apr 24 2005
next sibling parent reply Nils Hensel <nils.hensel web.de> writes:
Derek Parnell schrieb:
 I don't know the answer to that, however I wrote a utility that analyzes
 your application's source code files and sort of creates an on-the-fly
 command line for you. It then compiles only those sources that need to be
 made up to date, and places all the right objects onto the command line for
 you.

I know of your utility and think it's a great idea. Unfortunately it doesn't work for me, except for very simple programs that don't use external libraries. At the moment I'm experimenting with wxD and when I try to use build I get the following: C:\MySource\D\wxTest>c:\dmd\bin\build_win_2.03.exe HexMonster.d c:\dmd\bin\..\..\dm\bin\link.exe hexzentrisch+wx\wx+wxdefs+HexMonster,HexMonster .exe,,user32+kernel32,HexMonster.def/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved wx\wx.obj Error 2: File Not Found wx\wx.obj --- errorlevel 1 So I stick with plain old dmd and hope build will build my programs as wel one day :) Nils
Apr 24 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 24 Apr 2005 13:37:51 +0200, Nils Hensel wrote:

 Derek Parnell schrieb:
 I don't know the answer to that, however I wrote a utility that analyzes
 your application's source code files and sort of creates an on-the-fly
 command line for you. It then compiles only those sources that need to be
 made up to date, and places all the right objects onto the command line for
 you.

I know of your utility and think it's a great idea. Unfortunately it doesn't work for me, except for very simple programs that don't use external libraries. At the moment I'm experimenting with wxD and when I try to use build I get the following: C:\MySource\D\wxTest>c:\dmd\bin\build_win_2.03.exe HexMonster.d c:\dmd\bin\..\..\dm\bin\link.exe hexzentrisch+wx\wx+wxdefs+HexMonster,HexMonster .exe,,user32+kernel32,HexMonster.def/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved wx\wx.obj Error 2: File Not Found wx\wx.obj --- errorlevel 1

I hope you also read the documentation that came with it and with DMD ;-) You will note that external libraries can be specified in the source code in a similar way that external modules can. In fact, there are two ways of doing it. pragma(lib, wxD.lib); or version (build) pragma(link, wxD.lib);
 
 So I stick with plain old dmd and hope build will build my programs as 
 wel one day :)

Fine. I built this tool for my own usage and I no longer have to put up with arcane makefiles and their maintenance any more. You do what you see fit, of course. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 24/04/2005 9:42:00 PM
Apr 24 2005
parent reply Nils Hensel <nils.hensel web.de> writes:
Derek Parnell schrieb:
 I hope you also read the documentation that came with it and with DMD ;-) 
 
 You will note that external libraries can be specified in the source code
 in a similar way that external modules can. In fact, there are two ways of
 doing it.
 
   pragma(lib, wxD.lib);

Well, that's exactly what I did. I wrote a module I called wxdefs that includes all the necessary pragma statements and then I import this module in my main program. But build can't handle this I'm afraid. This module actually was the reason for my initial posting. I don't really see why I have to add it to the dmd command line as I already told the compiler that I'm using it through the import statement. Maybe a pragma(include, "mymodule.d") could be of use though I really think it would be easier if the compiler would just automatically add mymodule to the link list.
 Fine. I built this tool for my own usage and I no longer have to put up
 with arcane makefiles and their maintenance any more. You do what you see
 fit, of course.

If build would work for me I'd use it, but sadly it doesn't. Regards, Nils
Apr 24 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 24 Apr 2005 14:07:36 +0200, Nils Hensel wrote:

 Derek Parnell schrieb:
 I hope you also read the documentation that came with it and with DMD ;-) 
 
 You will note that external libraries can be specified in the source code
 in a similar way that external modules can. In fact, there are two ways of
 doing it.
 
   pragma(lib, wxD.lib);

Well, that's exactly what I did. I wrote a module I called wxdefs that includes all the necessary pragma statements and then I import this module in my main program. But build can't handle this I'm afraid.

Well so am I! Look, I want it to handle that sort of situation and so far my testing says it can. Can I have a look at your 'wxdefs' file to see if I can replicate the problem at my end - so I can improve Build if it needs it. Does it look like this ... [wxdefs.d] version(build) { pragma(link, "lib1.lib"); pragma(link, "lib2.lib"); }
 This module actually was the reason for my initial posting. I don't 
 really see why I have to add it to the dmd command line as I already 
 told the compiler that I'm using it through the import statement.
 
 Maybe a
 
    pragma(include, "mymodule.d")
 
 could be of use though I really think it would be easier if the compiler 
 would just automatically add mymodule to the link list.

The Build documentation says that it already supports that pragma. version(build) pragma(include, "mymodule");
 Fine. I built this tool for my own usage and I no longer have to put up
 with arcane makefiles and their maintenance any more. You do what you see
 fit, of course.

If build would work for me I'd use it, but sadly it doesn't.

Well it could it you helped me improve it. Why are you so reluctant to give me details so I can help you, myself, and maybe others too? -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 12:39:53 AM
Apr 24 2005
parent reply Nils Hensel <nils.hensel web.de> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Derek Parnell schrieb:
 Well so am I! Look, I want it to handle that sort of situation and so far
 my testing says it can. Can I have a look at your 'wxdefs' file to see if I
 can replicate the problem at my end - so I can improve Build if it needs
 it. 

I attached the file to this posting.
 Does it look like this ...
 
 [wxdefs.d]
 version(build)
 {
   pragma(link, "lib1.lib");
   pragma(link, "lib2.lib");
 }

I changed it so it does but this doesn't build as well. This file is also attached.
 The Build documentation says that it already supports that pragma.
 
   version(build) pragma(include, "mymodule");

Happy to see that there is a documentation. You don't mention that on your website. I assumed the .zip file was just the source so I only downloaded the .exe file.
If build would work for me I'd use it, but sadly it doesn't.

Well it could it you helped me improve it. Why are you so reluctant to give me details so I can help you, myself, and maybe others too?

I'm sorry I don't mean to hold back anything. What details do you need that I didn't mention before? Nils
Apr 24 2005
next sibling parent J C Calvarese <jcc7 cox.net> writes:
Nils Hensel wrote:
 Derek Parnell schrieb:

 
 Happy to see that there is a documentation. You don't mention that on 
 your website. I assumed the .zip file was just the source so I only 
 downloaded the .exe file.

There's online documentation, too (through the magic of SVN): http://svn.dsource.org/svn/projects/build/trunk/Docs/index.htm -- jcc7 http://jcc_7.tripod.com/d/
Apr 24 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 24 Apr 2005 20:31:00 +0200, Nils Hensel wrote:

 Derek Parnell schrieb:

error, as I expected them to. So now I'm thinking that maybe I don't understand the error you are seeing. Can I ask another favour from you; can you run Build again with either or both of these 'wsdefs' files, but this time use the -V switch. This will display an enormous amount of information. Can you send me this stuff so I can analyze the error message(s)? e.g. build -V yourapp >build_dump.txt My email is ddparnell (a.t) bigpond (d.o.t) com
 Happy to see that there is a documentation. You don't mention that on 
 your website. I assumed the .zip file was just the source so I only 
 downloaded the .exe file.

Huh? Of course there is documentation. Why would anyone release a product without documentation? That just doesn't make sense. By the way, I didn't mention that there was any source code in the ZIP file either ;-) But I get the point; I'll explicitly release the documentation as a separate download for those who want to read about it before trying it. Thanks for the heads-up. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 8:27:27 AM
Apr 24 2005
parent Derek Parnell <derek psych.ward> writes:
 -----Original Message-----
 From: Nils Hensel
 Sent: Monday, 25 April 2005 9:04 AM
 To: ddparnell (a.t) bigpond (d.o.t) com
 Subject: Build problems
 
 Hello Derek,
 
 here are the files you requested. The first run was with the 
 unmodified wxdefs and the second one is after modification.
 But you will notice this anyhow when you take a look at them.
 

Okay, I think I can see the mistake. It seems that all the .obj files, except for wx\wx.obj is up to date, but Build is not recognizing that fact, so doesn't recompile wx\wx.d. You should get it to work ok with the '-full' switch, which forces a full recompile of all sources. Once this gets it into sync again, then build should work as advertised. In the meantime, I'll fix the bug for the next release. Thanks for helping me find this mistake of mine. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 2:17:22 PM
Apr 24 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 24 Apr 2005 20:31:00 +0200, Nils Hensel wrote:

 Derek Parnell schrieb:
 Well so am I! Look, I want it to handle that sort of situation and so far
 my testing says it can. Can I have a look at your 'wxdefs' file to see if I
 can replicate the problem at my end - so I can improve Build if it needs
 it. 


I finally managed to replicate the messages you are getting. And it seems that the mistake is your area. Build is working okay-ish. It could give a better message, but for now its doing its job okay. It seems that you have inside HexMonster.d a line that reads something like ... import wx.wd; but the file "wx\wx.d" does not exist! The mistake, if you like to call it that, is that Build wrongly assumes that wx\wx.d is up-to-date because wx\wx.d *and* wx\wx.obj both don't exist. So Build then incorrectly adds wx\wx.obj to the command line. What it should do is issue a message the requested module "wx.wx" cannot be found, instead of letting DMD find that out. The problem goes away once I create wx\wx.d -- Derek Parnell Melbourne, Australia 25/04/2005 4:06:40 PM
Apr 24 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 25 Apr 2005 16:12:49 +1000, Derek Parnell wrote:

 I finally managed to replicate the messages you are getting. And it seems
 that the mistake is your area. Build is working okay-ish. It could give a
 better message, but for now its doing its job okay.

Weird! Now I can't replicate the errors again. While testing my changes, I tried to get the same message you were getting, and now I can't do it. So I'm once again uncertain as to what's causing the messages you get. Oh well, back to analyzing... -- Derek Parnell Melbourne, Australia 25/04/2005 5:01:08 PM
Apr 25 2005
prev sibling parent reply Nils Hensel <nils.hensel web.de> writes:
Derek Parnell schrieb:
 It seems that you have inside HexMonster.d a line that reads something like
 ...
 
   import wx.wd;

That is correct.
 but the file "wx\wx.d" does not exist! 

Well, it does exist along the include path. I copied the wx directory to c:\dmd\src\ because that directory was already in my include path. in my sc.ini it reads: DFLAGS="-I% P%\..\src\phobos";C:\MySource\D\dfl;C:\dmd\src; which works fine with dmd. Perhaps build should check DFLAGS and look for missing *.d files there? Nils
Apr 25 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 25 Apr 2005 12:19:01 +0200, Nils Hensel wrote:

 Derek Parnell schrieb:
 It seems that you have inside HexMonster.d a line that reads something like
 ...
 
   import wx.wd;

That is correct.
 but the file "wx\wx.d" does not exist! 

Well, it does exist along the include path. I copied the wx directory to c:\dmd\src\ because that directory was already in my include path. in my sc.ini it reads: DFLAGS="-I% P%\..\src\phobos";C:\MySource\D\dfl;C:\dmd\src; which works fine with dmd. Perhaps build should check DFLAGS and look for missing *.d files there?

Bingo! Build already does use the DFLAGS entry in the sc.ini file. However, it obviously parses it differently to DMD. Build only saw the -I flag from the quoted section. The stuff out of the quotes it ignored. Had you written DFLAGS="-I% P%\..\src\phobos;C:\MySource\D\dfl;C:\dmd\src;" it would have added all three paths and not just the first one. I should have picked this up earlier as the clue is in the -V display.
 Line 6: DFLAGS="-Ic:\dmd\bin\..\src\phobos";C:\MySource\D\dfl;C:\dmd\src;
 added root from config file c:\dmd\src\phobos\

But it should have also had
 added root from config file C:\MySource\D\dfl
 added root from config file c:\dmd\src\

I'll fix this bug tonight. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 9:08:45 PM
Apr 25 2005
parent Nils Hensel <nils.hensel web.de> writes:
Derek Parnell schrieb:
 Bingo! Build already does use the DFLAGS entry in the sc.ini file. However,
 it obviously parses it differently to DMD. Build only saw the -I flag from
 the quoted section. The stuff out of the quotes it ignored. Had you written 
 
  DFLAGS="-I% P%\..\src\phobos;C:\MySource\D\dfl;C:\dmd\src;"
 
 it would have added all three paths and not just the first one. 
 I should have picked this up earlier as the clue is in the -V display.
 I'll fix this bug tonight.

Great! I'm glad I could help catching this bug and am looking forward to using build in the future. Greetz, Nils
Apr 25 2005
prev sibling parent reply "Bob W" <nospam aol.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:voiulhbsvc09.1dk3johj3w80g$.dlg 40tude.net...
.............
 You can find out more at http://www.dsource.org/projects/build

Is the dsource.org site frequently down? Tried to access it a few times, but to no avail.
Apr 24 2005
parent J C Calvarese <jcc7 cox.net> writes:
Bob W wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:voiulhbsvc09.1dk3johj3w80g$.dlg 40tude.net...
 .............
 
You can find out more at http://www.dsource.org/projects/build

Is the dsource.org site frequently down? Tried to access it a few times, but to no avail.

I think there have been problems with too much traffic on weekdays from about 8-10 am Central Time (US), but I don't know of any common problems on weekends. It's been working fine for me today. -- jcc7 http://jcc_7.tripod.com/d/
Apr 24 2005
prev sibling next sibling parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Nils Hensel wrote:

 Let's say I have a module called mymodule which contains some data and
 I write in example.d:
 
   import mymodule;
 
 and compile it like
 
   dmd example.d
 
 I get
 
   Error 42: Symbol Undefined IMAGINE_NAME_OF_DATA_HERE
 
 unless I state that mymodule.[d|obj] shall be compiled/linked as well.
 
 Isn't it completely obvious from the import statement that I intend to 
 use it? Why does it have to be explicitly declared?

I'm not sure it's the only reason; but one reason is that the imports and the implementations might be done in two *different* .d files, or the implementation could even be in another language for some modules. If it would include the same module for linking too, that it does for compiling - then the current setup with import modules wouldn't work ? But it does make things a little more tedious to use, when all in D. And I think it could definitely use some more documentation... digitalmars.D/15626 I've collected the objects needed for "mymodule" into libmymodule.a, and then I can link to this static library instead of the .d files ? (this would be the same way that Phobos, Mango, etc. does it, I believe) D links rather differently from what Python and Java does? (But like C) "pragma lib" should help a bit, but still a pain to get it portable... Thankfully, wrapping C libraries in D doesn't always generate objects. --anders
Apr 24 2005
parent reply Nils Hensel <nils.hensel web.de> writes:
Anders F Björklund schrieb:
 I'm not sure it's the only reason; but one reason is that the imports
 and the implementations might be done in two *different* .d files, or
 the implementation could even be in another language for some modules.

I see the point.
 If it would include the same module for linking too, that it does for
 compiling - then the current setup with import modules wouldn't work ?
 But it does make things a little more tedious to use, when all in D.

Agreed.
 And I think it could definitely use some more documentation...
 digitalmars.D/15626

Documentation is D's biggest lack.
 "pragma lib" should help a bit, but still a pain to get it portable...

It's a pity that there's no pragma(link, "mymodule.obj") That would be enough to suit my needs even though I still believe it's ugly. Nils
Apr 24 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 24 Apr 2005 14:53:18 +0200, Nils Hensel wrote:

[snip]
 
 It's a pity that there's no pragma(link, "mymodule.obj")
 That would be enough to suit my needs even though I still believe it's ugly.

Ok, the Build docs do not mention it, but you can reference object files on its pragma(link) statements. version(build) pragma(link, "mymodule.obj"); I'll update the docs about that one. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 12:33:13 AM
Apr 24 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Nils Hensel" <nils.hensel web.de> wrote in message
news:d4g4md$muc$1 digitaldaemon.com...
 Anders F Björklund schrieb:
 I'm not sure it's the only reason; but one reason is that the imports
 and the implementations might be done in two *different* .d files, or
 the implementation could even be in another language for some modules.

I see the point.

and I did find that I could work around it... but like you Anders pointed out, it's a bit tedious. TZ
Apr 24 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
TechnoZeus wrote:

 That's exactly what was happening in my case,
 and I did find that I could work around it...
 but like you Anders pointed out,
 it's a bit tedious.

To be perfectly clear, I just that it is more work to use a library module made in D from D than what it is in e.g. the Python or Java languages/runtimes... But if that library is external to those (Python/Java), then the "hassle" here is about the same in all of them. (Usually done by loading a shared library with the code) It's really not very different from how you link C/C++. And for the simple D stuff you can usually throw all .d files on "dmd" at once - and the rest can use a library ? Which reminds me that I should give Build 2.0 a whirl... --anders PS. Short porting tip: If a C header file that you translate says something like: extern void foo(void); #define bar foo Then you can use "alias" in D: extern(C): void foo(); alias foo bar; If you instead use a wrapper: extern(C): void foo(); void bar() { foo(); } You get new "bar" object code, and thus must link to this D code later ? (for the simple alias, linking with the translated C library is enough) Sometimes, you need the wrappers though... Either the #define above adds a few parameters, or it's a complex macro "function" in itself.
Apr 25 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d4i6ak$17ni$1 digitaldaemon.com...
 TechnoZeus wrote:

 That's exactly what was happening in my case,
 and I did find that I could work around it...
 but like you Anders pointed out,
 it's a bit tedious.

To be perfectly clear, I just that it is more work to use a library module made in D from D than what it is in e.g. the Python or Java languages/runtimes... But if that library is external to those (Python/Java), then the "hassle" here is about the same in all of them. (Usually done by loading a shared library with the code) It's really not very different from how you link C/C++. And for the simple D stuff you can usually throw all .d files on "dmd" at once - and the rest can use a library ? Which reminds me that I should give Build 2.0 a whirl... --anders PS. Short porting tip: If a C header file that you translate says something like: extern void foo(void); #define bar foo Then you can use "alias" in D: extern(C): void foo(); alias foo bar; If you instead use a wrapper: extern(C): void foo(); void bar() { foo(); } You get new "bar" object code, and thus must link to this D code later ? (for the simple alias, linking with the translated C library is enough) Sometimes, you need the wrappers though... Either the #define above adds a few parameters, or it's a complex macro "function" in itself.

Thanks. Not working with any C though... but still, it was in interesting explanation. :) TZ
Apr 25 2005
prev sibling next sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Nils Hensel" <nils.hensel web.de> wrote in message
news:d4fu8l$hbr$1 digitaldaemon.com...
 Hi,

 I was wondering why imported modules are not automatically linked. As I
 have been tinkering mostly with Python in the last few years I expected
 an imported module to be usable right away.

 Let's say I have a module called mymodule which contains some data and I
 write in example.d:

    import mymodule;

 and compile it like

    dmd example.d

 I get

    Error 42: Symbol Undefined IMAGINE_NAME_OF_DATA_HERE

 unless I state that mymodule.[d|obj] shall be compiled/linked as well.

 Isn't it completely obvious from the import statement that I intend to
 use it? Why does it have to be explicitly declared?

 Regards,
 Nils

I've noticed this also.... and felt the same way about it. Walter, is there any plan to change this? TZ
Apr 24 2005
parent reply J C Calvarese <jcc7 cox.net> writes:
TechnoZeus wrote:
 "Nils Hensel" <nils.hensel web.de> wrote in message
news:d4fu8l$hbr$1 digitaldaemon.com...
 
Hi,

I was wondering why imported modules are not automatically linked. As I
have been tinkering mostly with Python in the last few years I expected
an imported module to be usable right away.

Let's say I have a module called mymodule which contains some data and I
write in example.d:

   import mymodule;

and compile it like

   dmd example.d

I get

   Error 42: Symbol Undefined IMAGINE_NAME_OF_DATA_HERE

unless I state that mymodule.[d|obj] shall be compiled/linked as well.

Isn't it completely obvious from the import statement that I intend to
use it? Why does it have to be explicitly declared?


...
 I've noticed this also.... and felt the same way about it.
 
 Walter, is there any plan to change this?
 
 TZ

It was like pulling teeth just getting Walter to add the library pragma (which he did finally add). What exactly do you have in mind? I think the major problem is that sometimes separate .obj's are used and sometimes the .obj's are stored in a .lib. Can DMD guess correctly where it's stored? What is it guesses incorrectly. Derek is trying to handle these issues (and doing a great job) with the Build utility (http://www.dsource.org/projects/build/), but it's not as simple as one might think. I think Walter would rather spend his time getting the bugs out of DMD, so you might just try to using Build and ask Derek to add some features if it doesn't work the way you want it to work. It's just a suggestion. Feel free to ignore it. -- jcc7 http://jcc_7.tripod.com/d/
Apr 24 2005
next sibling parent "Charlie" <charles jwavro.com> writes:
 Derek is trying to handle
 these issues (and doing a great job) with the Build utility
 (http://www.dsource.org/projects/build/), but it's not as simple as one
 might think.

Yea this tool is awesome, let Walter work on the big stuff, build works awesome for me, defintely worth expending the time to learn how to use it :) Charlie "J C Calvarese" <jcc7 cox.net> wrote in message news:d4h2ki$9uv$1 digitaldaemon.com...
 TechnoZeus wrote:
 "Nils Hensel" <nils.hensel web.de> wrote in message


Hi,

I was wondering why imported modules are not automatically linked. As I
have been tinkering mostly with Python in the last few years I expected
an imported module to be usable right away.

Let's say I have a module called mymodule which contains some data and I
write in example.d:

   import mymodule;

and compile it like

   dmd example.d

I get

   Error 42: Symbol Undefined IMAGINE_NAME_OF_DATA_HERE

unless I state that mymodule.[d|obj] shall be compiled/linked as well.

Isn't it completely obvious from the import statement that I intend to
use it? Why does it have to be explicitly declared?


...
 I've noticed this also.... and felt the same way about it.

 Walter, is there any plan to change this?

 TZ

It was like pulling teeth just getting Walter to add the library pragma (which he did finally add). What exactly do you have in mind? I think the major problem is that sometimes separate .obj's are used and sometimes the .obj's are stored in a .lib. Can DMD guess correctly where it's stored? What is it guesses incorrectly. Derek is trying to handle these issues (and doing a great job) with the Build utility (http://www.dsource.org/projects/build/), but it's not as simple as one might think. I think Walter would rather spend his time getting the bugs out of DMD, so you might just try to using Build and ask Derek to add some features if it doesn't work the way you want it to work. It's just a suggestion. Feel free to ignore it. -- jcc7 http://jcc_7.tripod.com/d/

Apr 24 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4h2ki$9uv$1 digitaldaemon.com...
*snip*
 It was like pulling teeth just getting Walter to add the library pragma
 (which he did finally add). What exactly do you have in mind?

 jcc7
 http://jcc_7.tripod.com/d/

I didn't actually have anything specific in mind at all. It was simply a question. Mainly, I was wondering if Walter already had something in mind. TZ
Apr 24 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Nils Hensel" <nils.hensel web.de> wrote in message
news:d4fu8l$hbr$1 digitaldaemon.com...
 I was wondering why imported modules are not automatically linked. As I
 have been tinkering mostly with Python in the last few years I expected
 an imported module to be usable right away.

Because it isn't always obvious what the name of the imported object file is - or even if it is in a library instead. Also, one does not always want to link in the module, for example, if it contains references to C global variables.
Apr 24 2005