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:
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:


I ran a test with both of the files you provided and they worked without
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...
http://www.digitalmars.com/drn-bin/wwwnews?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...
 http://www.digitalmars.com/drn-bin/wwwnews?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.


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.

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




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
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?


*snip*

 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