Community

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

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

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

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

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

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

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

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

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