I've gone about building static libraries for nanovg and arsd. (I'm feeling pretty good about what I've learned in the last couple days, so I gave it a whirl.)

arsd has ttf.d and stb_truetype.d. Comments in stb_truetype.d say use ttf.d instead.

nanovg has a ttf.d also.

There are three ttf.d's to choose from.

nanovg has linker errors:
..\..\..\lib\libnanovg.lib(nanovg)
 Error 42: Symbol Undefined _D2iv3stb3ttf25stbtt_ScaleForPixelHeightFPxS2iv3stb3ttf14stbtt_fontinfofZf

I'm not sure I fully understand name mangling, but it looks like nanovg wants to use iv\stb\ttf.d from it's own source tree. But Ketmar said "p.s. you will also need stb_ttf port, arsd repo has it under the name "ttf.d"."

So which ttf.d should I use? Does it matter?

I've gained enough confidence in the last couple days to go ahead and use trial and error to sort this out. I thought I'd let you guys chime in.

Perhaps Ketmar intended to remove his copy of ttf.d from his repo?

Regards,
Jason C. Wells

On Thursday, 27 October 2016 at 01:48:54 UTC, Jason C. Wells wrote:
> I'm not sure I fully understand name mangling, but it looks like nanovg wants to use iv\stb\ttf.d from it's own source tree. But Ketmar said "p.s. you will also need stb_ttf port, arsd repo has it under the name "ttf.d"."
>
> So which ttf.d should I use? Does it matter?

it really doesn't, but you should have only one. ;-) the idea is that nanovg tries to import several stb_truetype ports (including iv.freetype bindings) and will use the first one that imported successfully. it is, again, works nice with rdmd and full IV repo, but may fail if you'll pass Adam's ttf.d in command line, while there is iv.ttf accessible on the disk. in this case importing of iv.ttf will succeed, but the code will be generated for arsd.ttf. oops.

> Perhaps Ketmar intended to remove his copy of ttf.d from his repo?

quite the contrary. ;-) if anything resides in IV, then it is preferred thing to use with any IV modules. i strongly suggest you to move to rdmd, it can do most of such things for you. ;-)

as for nanovg, the preferred is iv.freetype, actually. then iv.ttf, then arsd.ttf. btw, you can find me on IRC channel (and Adam too), and ask your questions in real-time (well, if we are online ;-).

On Thursday, 27 October 2016 at 01:48:54 UTC, Jason C. Wells wrote:
> arsd has ttf.d and stb_truetype.d. Comments in stb_truetype.d say use ttf.d instead.

My ttf.d is just version 1.2 of stb_truetype.d basically... the two files are very similar and should be generally compatible.

ketmar's ttf.d I think is about 95% the same (we both ported the same C library), but slightly different, including a different module name... so you should be able to compile in both my ttf.d and his ttf.d at the same time.

Though I betcha his alone will be fine, or mine alone might be fine if you change the import statement (use `import arsd.ttf;` rather than `import iv.stb.ttf;`, the rest are probably compatible.)

Adding iv\stb\ttf.d cleared up most of the remaining linker errors.

While compiling iv\nanovg_demo\example.d I am left with:

bin\example.obj(example)
 Error 42: Symbol Undefined _D2iv6nanovg3oui12__ModuleInfoZ

bin\example.obj(example)
 Error 42: Symbol Undefined _D2iv6nanovg12__ModuleInfoZ

..\..\..\lib\libarsd.lib(jpeg)
 Error 42: Symbol Undefined _D2iv3vfs12__ModuleInfoZ

I have no idea where this ModuleInfoZ thing is coming from. I searched the sources for the string "ModuleInfoZ" but that string appears only in obj/def files. I suppose that the compile/linker adds this symbol to object files.

How do I fix the missing ModuleInfoZ symbol?

I am quite surprised that arsd is looking for iv\vfs\_something_.

I should mention that I have been "picky" about which files I included on the dmd command line.

BTW, I am not ignoring you guys when I haven't used rdmd ( I tried briefly but got stuck) or specifying all *.d files on the command line (did that with some success). My learning process is very organic and trial and error.

I appreciate what you are doing for me. Thanks for the invite to chat on irc. I don't have an urgent need so I'll post here. Maybe other noobs will make use of this.

On Thursday, 27 October 2016 at 02:12:34 UTC, Jason C. Wells wrote:
>  Error 42: Symbol Undefined _D2iv6nanovg3oui12__ModuleInfoZ

That means some module was imported but not compiled. You can run the `ddemangle` program that comes with dmd to translate it (or you'll get used to just reading it by eyeball - the pattern is _Dxyyy, repeated. The x is a number saying how long the next name is, and the yyy is the next part of the name. So 2iv6nanovg becomes iv.nanovg).

That means the iv.nanovg.oui was imported somewhere but not compiled in. The example surely uses it. ModuleInfo is auto-generated by the compiler for each module.

> I am quite surprised that arsd is looking for iv\vfs\_something_.

ketmar and I semi-collaborate... our stuff is independent, but we know a number of more advanced tricks to selectively import if a file is available on the system.

So my jpeg.d (which was actually primarily authored by ketmar, well, he ported a C library and put an interface on top, then merged with my old jpg.d) will see if iv.vfs is available on the file system, and if it is, it will import it.

That works well if you just download a few files at a time (which is how I generally distribute my libs, I say "download file.d and other.d"), but if you downloaded *everything*, it will see it is there and try to show additional features.

But since you aren't compiling everything you have available, it sees it is there...but it isn't all built.

On Thursday, 27 October 2016 at 02:18:26 UTC, Jason C. Wells wrote:
> My learning process is very organic and trial and error.

yeah, that's us too :) With time, knowing all the details is better - you'll learn a lot though the start can be slower.

I usually keep my code simple, but there's a few fancy tricks mixed in too (like lazy imports or speculative modules...) so sometimes it is harder than you'd expect.

Also, my "package" is more just a collection of independent modules you can add to your project and hack on than something intended to be compiled separately. So you're kinda going against the grain... but it is educational and you can make it work!

On Thursday, 27 October 2016 at 02:12:34 UTC, Jason C. Wells wrote:
> I have no idea where this ModuleInfoZ thing is coming from.

as Adam said, it means that it imports some module, and you didn't passed it to dmd. in this case, it is iv.nanovg.oui package (this is Blender-like GUI controls -- not a full GUI package, just GUI controls and some simple things). example is using that to draw OUI window to impress the end user. ;-)

> How do I fix the missing ModuleInfoZ symbol?

just add everything from iv/nanovg/oui to dmd invocation.

> BTW, I am not ignoring you guys when I haven't used rdmd ( I tried briefly but got stuck) or specifying all *.d files on the command line (did that with some success). My learning process is very organic and trial and error.

there is nothing wrong in that, of course. i keep telling about rdmd only 'cause it is easier to get at least *something* with it. but you'll eventually get it working with dmd too, and this is harder, but better way if you want to really grok the things. ;-)

I have a nice screen shot of the nanovg demo running. The old xeyes is a nice touch. I was excited to post the photo here but it looks like I cannot. I can tell by the animations that this will be precisely what I need to animate svg based instrumentation.

I ended up making one more static library for iv\vfs. I also ended up editing iv\vfs\package.d to comment out the reference to arcs. I was getting tired of following the missing symbols down the rabbit hole.

The ModuleInfoZ missing symbols were due to the package.d files in every case. I'll have to read up on those a bit more.

Oh and, as the end user, that demo has me all impressed. :)

Regards,
Jason C. Wells