www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to use an existing D package in Visual D?

reply realhet <real_het hotmail.com> writes:
Hello,

I have all my D packages in the c:\D\libs\ directory.
I added this path to the PropertyPages/Compiler/Additional Import 
Paths field.

In the project source file I imported a module from my package 
using "import het.utils;"
Also used a function from it.

The syntax highlighter worked good, and the compiler was able to 
build main.obj file.

But I can't find the het.utils.obj file nowhere. Also the linker 
is unable to link the things in it.

My question is that how can I add an external package the right 
way to my project in Visual D?

I'm planning to use that package from other projects too, so I 
want to keep it in one place on my HDD.

Thank You in advance!
Apr 05 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 5 April 2022 at 09:26:54 UTC, realhet wrote:

 Hello,

 I have all my D packages in the c:\D\libs\ directory.
 I added this path to the PropertyPages/Compiler/Additional 
 Import Paths field.

 In the project source file I imported a module from my package 
 using "import het.utils;"
 Also used a function from it.

 The syntax highlighter worked good, and the compiler was able 
 to build main.obj file.

 But I can't find the het.utils.obj file nowhere. Also the 
 linker is unable to link the things in it.

 My question is that how can I add an external package the right 
 way to my project in Visual D?

 I'm planning to use that package from other projects too, so I 
 want to keep it in one place on my HDD.

 Thank You in advance!


Importing modules is only for showing the compiler which symbols 
are available for you to use. By default, it does not cause them 
to be compiled or linked. You should compile the existing package 
as a library, then add the library file to the linker settings in 
VisualD.
Apr 05 2022
parent realhet <real_het hotmail.com> writes:
On Tuesday, 5 April 2022 at 09:57:29 UTC, Mike Parker wrote:

 On Tuesday, 5 April 2022 at 09:26:54 UTC, realhet wrote:
 You should compile the existing package as a library, then add 
 the library file to the linker settings in VisualD.


Thank You for the fast help!

Currently I have my own build system which works similar to 
Delphi(native target):

You specify the main module and the package paths. Press F9. And 
the it AUTOMATICALLY discovers all the referenced module 
hierarchy and compiles it then finally producing an .exe.
It also does compiled .obj file caching, so only the modules I 
changed and the modules that using the changed modules will be 
recompiled.
I can do this module caching for myself, since the LDC compiler 
has the -allinstances flag.
I switched from LDC 1.20 to 1.28 and I love the new internal 
linker. It will eliminate a lot of MS linker specific hacking 
from my build tool. I can just give LDC a bunch of sources, 
objects, and libs. And it does all the job intelligently.

I'm talking about this if you want to peek: 
https://github.com/realhet/hetlib/blob/master/het/HLDC/BuildSys.d
It basically launches an LDC2 instance for each of the changed 
modules and calls the linker when all finished. A debug compile 
takes 15 sec for a 40KLOC project(hierarchically including a few 
packages too) if I only change the main D file.

Is this fast and light weight approach exists at all in 
VisualStudio?
I heard something about "incremental build" in VisualStudio, but 
I think even if it is working with D, it can't step over the 
static library boundaries that you mentioned I have top use for 
the packages.
Apr 05 2022