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?

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.

On Saturday, 22 October 2016 at 01:31:25 UTC, Mike Parker wrote:
> * 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.


That's what I recommend. Just

dmd yourfile.d yourotherfiles.d color.d simpledisplay.d whatever_other_of_my_or_ketmars_files_you_use.d


That just works consistently.

First, thank you for taking the time to help me with something that should be trivial.

I've done the above listing of file on the command line but I'm still stuck. I'm starting to think that I might actually be tripping over bugs, but I'm not confident enough to believe that without some confirmation.

I have the following directory structure from the zipfiles found in the repositories posted by ketmar.

nanovg_demo
- iv (was renamed from nanovg based on dmd error messages)
-- arsd (was renamed from arsd-master based on dmd error messages)

To proceed, I would attempt a compile. Then I would add the file that was producing an error to the command line and try again. I got this far.

Via cmd.exe:

  nanovg_demo>dmd example.d iv\arsd\color.d iv\arsd\simpledisplay.d iv\perf.d

  iv\perf.d(41): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be
  imported with 'import iv.nanovg.nanovg;'

  demo.d(6): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be
  imported with 'import iv.nanovg.nanovg;'

iv/nanovg/nanovg does not exist in the source code zip files. (I was reluctant to duplicate nanonvg into iv\nanovg because somewhere I learned that copy-pasting code is a bad idea.)

  demo.d(7): Error: module oui is in file 'iv\nanovg\oui.d' which cannot be read

oui.d does not exist anywhere. There is, however, a oui directory.

As a side note, I did have some success. I am able to compile nanovg.lib quite easily (from tips provided a few messages ago). It's when I try to compile the demo that I get stuck.

Regards,
Jason C. Wells

On Saturday, 22 October 2016 at 03:59:16 UTC, Jason C. Wells wrote:
> First, thank you for taking the time to help me with something that should be trivial.
>
> I've done the above listing of file on the command line but I'm still stuck. I'm starting to think that I might actually be tripping over bugs, but I'm not confident enough to believe that without some confirmation.

I think I can confidently assure you that you aren't running into any bugs here.

>
> I have the following directory structure from the zipfiles found in the repositories posted by ketmar.
>
> nanovg_demo
> - iv (was renamed from nanovg based on dmd error messages)
> -- arsd (was renamed from arsd-master based on dmd error messages)
>
> To proceed, I would attempt a compile. Then I would add the file that was producing an error to the command line and try again. I got this far.
>
> Via cmd.exe:
>
>   nanovg_demo>dmd example.d iv\arsd\color.d iv\arsd\simpledisplay.d iv\perf.d
>
>   iv\perf.d(41): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be
>   imported with 'import iv.nanovg.nanovg;'
>
>   demo.d(6): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be
>   imported with 'import iv.nanovg.nanovg;'
>
> iv/nanovg/nanovg does not exist in the source code zip files. (I was reluctant to duplicate nanonvg into iv\nanovg because somewhere I learned that copy-pasting code is a bad idea.)

looking at kemar's repository, the nanovg.d module belongs to the iv.nanovg package. I don't know what the zip directory tree looks like, but you should have this:

- iv
-- nanovg
--- fui
--- nanovg.d
--- oui
--- package.d
--- perf.d
--- svg.d

As for the asrd stuff, it shouldn't bee in the iv tree at all. You should do something like this:

- import
-- iv
-- arsd

Both iv and arsd are top-level packages, so they ought to be independent of each other.

>
>   demo.d(7): Error: module oui is in file 'iv\nanovg\oui.d' which cannot be read
>
> oui.d does not exist anywhere. There is, however, a oui directory.

If you look at the source for demo.d, you'll see that it makes use of the oui package. That means the everything there also needs to be compiled and linked into the binary, but you haven't given those files to the compiler.


>
> As a side note, I did have some success. I am able to compile nanovg.lib quite easily (from tips provided a few messages ago). It's when I try to compile the demo that I get stuck.

Which files did you add into nanovg.lib? Everything in the iv.nanovg packages and subpackages, or just the ones you use directly? It's best to compile all of them into the lib, then any that are used indirectly by each other are also available.

You've dived right into a multi-module projects without a full understanding of imports and linking. I suggest you back up a bit and get familiar with the process before tackling ketmar and Adam's stuff. If they used dub, it would be a very easy process. Since they don't, and you have to manage it all manually, you need a solid understanding of how DMD handles this stuff and why you are getting the error messages you see.

Try playing around with simple single-function modules, starting with something like this:

io.d:
```
void print(string s)
{
   import std.stdio : writeln;
   writeln(s);
}
```

main.d:
```
import io;
void main() { print("Hello, D!"); }
```

Compile both:
dmd main.d io.d

Compile separately:
dmd -c io.d
dmd main.d io.obj


Move the io.d module into a package, mylib.io:

- main.d
-- mylib
--- io.d

Add a module statement to the top of io.d:
```
module mylib.io;
```

Change the import in main.d:

```
import mylib.io;
```

Try again compiling together, then separately. Then move the mylib directory:

- main.d
-- lib
--- mylib
---- io.d

Then compile together and separately again. Try with and without -Ilib in both cases and see what happens. Add another single-function module into the mix. Compile mylib as a library and try again.

Just keep experimenting like this until you've worked out exactly what's going on and what the error messages mean. Then you can tackle the naonvg and arsd.

On Saturday, 22 October 2016 at 03:59:16 UTC, Jason C. Wells wrote:
>   nanovg_demo>dmd example.d iv\arsd\color.d iv\arsd\simpledisplay.d iv\perf.d
>
>   iv\perf.d(41): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be
>   imported with 'import iv.nanovg.nanovg;'
>
>   demo.d(6): Error: module iv.nanovg.nanovg from file iv\nanovg.d must be
>   imported with 'import iv.nanovg.nanovg;'
>
> iv/nanovg/nanovg does not exist in the source code zip files. (I was reluctant to duplicate nanonvg into iv\nanovg because somewhere I learned that copy-pasting code is a bad idea.)

it's way easier, actually. first, you don't have to place files into correct directories if you are passing all of them (files) as arguments to dmd. they don't even have to have correct names. "correct" file placement is required only if dmd should search for modules on his own.

second: you simply didn't pass all the required modules. perf.d depends on core nanovg engine, but you didn't passed that to dmd.

the easiest way is just pall *all* *.d files you have to dmd. don't try to be picky ;-), dmd is fast enougth that you can safely pass alot of sources to it. and there is no harm in providing dmd with "extra" modules.


as for "correct" placement (if you want it), it should be like that:

dmd -Imodroot main.d
main.d is your main D file, modroot is dir where all modules will be. it should be like that:

modroot/arsd/color.d
modroot/arsd/<other Adam's modules here>
modroot/iv/nanovg/nanovg.d
modroot/iv/nanovg/<other NanoVG files here, keeping subdirs>


also, pref.d module is completely unnecessary, it is just utility thingy to show FPS counter. ;-)


p.s. you will also need stb_ttf port, arsd repo has it under the name "ttf.d".

p.p.s. the easiest way to do everything is this:
mkdir modroot
cd modroot
git clone git://repo.or.cz/iv.d.git iv
git clone https://github.com/adamdruppe/arsd.git arsd
cd ..
rdmd -Imodroot main.d

;-)

Now I think I finally see where my hang up is.

If B imports C, and A imports B and C, you still have to tell A where to find C. C doesn't go along for the ride with B. Stated another way, A doesn't look inside B to find C. Stated yet another way, B does not expose C to A.

The statement above that I did not include nanovg.d on the command line finally clued me in. The statement that I was being "picky" about what to compile similarly helped.

sh$> dmd $(find . -name "*.d") <== a joke, sort of.

Eager to make the next try. Gotta run for a bit.

On Saturday, 22 October 2016 at 06:18:13 UTC, Mike Parker wrote:
> I think I can confidently assure you that you aren't running into any bugs here.

Thanks for the confirmation. It helps me to learn.

> You've dived right into a multi-module projects without a full understanding of imports and linking. I suggest you back up a bit and get familiar with the process before tackling ketmar and Adam's stuff. If they used dub, it would be a very easy process. Since they don't, and you have to manage it all manually, you need a solid understanding of how DMD handles this stuff and why you are getting the error messages you see.

I'm used to compiling stuff in FreeBSD land. They have a group of people who take care to manage the build process (the dub part, i presume). What you say above is correct. I don't understand imports and linking. I can read the docs and they make sense, but I don't quite get it yet.

Thanks for writing up that simple exercise. That's next.

I was able to compile a working executable by specifying almost all *.d files on the command line. It didn't render an image, but it did pop up a window with an error message saying it couldn't load an image. I'm calling that victory.

Regards,
Jason