Jump to page: 1 2 3
Thread overview
Automatically linking imports
Apr 24, 2005
Nils Hensel
Apr 24, 2005
Derek Parnell
Apr 24, 2005
Nils Hensel
Apr 24, 2005
Derek Parnell
Apr 24, 2005
Nils Hensel
Apr 24, 2005
Derek Parnell
Apr 24, 2005
Nils Hensel
Apr 24, 2005
J C Calvarese
Apr 24, 2005
Derek Parnell
Apr 25, 2005
Derek Parnell
Apr 25, 2005
Derek Parnell
Apr 25, 2005
Derek Parnell
Apr 25, 2005
Nils Hensel
Apr 25, 2005
Derek Parnell
Apr 25, 2005
Nils Hensel
Apr 24, 2005
Bob W
Apr 25, 2005
J C Calvarese
Apr 24, 2005
Nils Hensel
Apr 24, 2005
Derek Parnell
Apr 24, 2005
TechnoZeus
Apr 25, 2005
TechnoZeus
[Walter] Re: Automatically linking imports
Apr 24, 2005
TechnoZeus
Apr 24, 2005
J C Calvarese
Apr 24, 2005
Charlie
Apr 24, 2005
TechnoZeus
Apr 24, 2005
Walter
April 24, 2005
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


April 24, 2005
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
April 24, 2005
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
April 24, 2005
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
April 24, 2005
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
April 24, 2005
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
April 24, 2005
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
April 24, 2005
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
April 24, 2005
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
April 24, 2005
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


« First   ‹ Prev
1 2 3