Render SVG To Display And Update Periodically

[Mike Parker via Digitalmars-d-learn]

On Friday, 21 October 2016 at 23:16:55 UTC, Jason C. Wells wrote:
> I've tinkered with what you proposed. In the process I've 
> worked through a variety of errors and ended up doing things I 
> don't think are a good solution like duplication directories so 
> that a library can be found.
>
> Let me see if I understand how to piece together a build. Some 
> combination of three things need to be in agreement:
>
> 1 - the import statements need to point to a matching directory 
> structure
> 2 - the directory structure needs to be arranged such that the 
> imports can be found
> 3 - the compiler can be told directly on the command line where 
> imports are
>
> I'm reading 
> https://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows which seems to be the document I need to sort through this.
>
> I'll close out with this last question and then go study up. Am 
> I barking up the right tree?

Yes. The compiler needs to know where to find the imports you use 
in the form of D source files or import modules (.di). 
Additionally, the linker needs to know which object files or 
libraries it needs to combine with your compiled source to create 
the executable, be they generated from D code or C or C++, and 
where to find them.

By default, the compiler knows where to find the Phobos and 
DRuntime modules and also that it needs to pass phobos.lib (which 
also includes the DRuntime objects) to the linker, so you never 
have to specify those. Any other modules you import besides your 
own need to be handled in one of the following ways:

* They can be passed directly to the compiler along with your own 
source. This will cause them to be compiled and ultimately linked 
into the resulting binary.

* The compiler can be told where to find the source to those 
modules with the -I command line switch. This *does not* cause 
them to be compiled. The compiler will only parse them when one 
is imported so that it can determine which symbols are available 
in the module it is currently compiling. You will still need to 
ensure those third-party modules are compiled separately and 
given to the linker.

Here's are a couple examples of the second approach, using the 
following directory structure:

- libraries
-- import
--- arsd
---- color.d
---- terminal.d
-- lib
- myprojects
-- foo
--- foo.d

Since Adam doesn't package the arsd stuff as a lib, you'll need 
to compile them yourself.

cd libraries
dmd -lib arsd/color.d arsd/terminal.d -odlib -ofarsd.lib

The -lib switch tells the compiler to create a library after it 
has compiled the files. The -od switch tells it to write the 
library in the lib directory and -od says the file name should be 
arsd.lib. This will result in the file libraries/lib/arsd.lib.

Alternatively, you could do this:

dmd arsd/color.d arsd/terminal.d -odlib

This will create lib/color.obj and lib/terminal.obj. It's easier 
to just create the library, which is an archive of both object 
files.

If you intend to use the Visual Studio linker, you will need to 
ensure you compile the library with the same flags you will use 
to compile the program (-m64 or -m32mscoff).

Now, assuming foo.d is the same code from my last post, cd into 
the myprojects/foo directory and do the following:

dmd -I../../import foo.d ../../lib/arsd.lib gdi32.lib user32.lib

The -I switch tells the compiler where it can find imports. It 
should always be the parent directory of the *package* you want 
to import. In this case, the package is arsd. A common mistake is 
to give import/arsd to the compiler.

In this case, I've passed the full path to the library because 
that's the easiest thing to do on Windows. It's possible to tell 
the linker which path to look in by using DMD's -L switch (which 
passes options directly to the linker), but OPTLINK and the MS 
linker use different switches for that. It's simpler just to pass 
the full path.

On Linux/Mac/*BSD, the extensions would be different: .obj -> .o, 
.lib -> .a. arsd.lib should be named libarsd.a. And the command 
line would look different as well:

dmd -I../../import foo.d -L-L../../lib -L-larsd

The -L switch is what you use to pass options to the linker. The 
first one, -L-L, gives the linker -L option, which on those 
systems tells the it append ../../lib to the library search path. 
The second one, -L-l (that's a lower-case 'L'), tells the linker 
to link with the library libarsd.a. You also need to link with 
any system dependencies the arsd modules have on those systems.