Here is my painpoint. I am trying to make a game engine using a combination of D and Swift, my two favorite programming languages. I chose D specifically for lower level features, like stuff for Vulkan and OpenGL as a 'learning experience'. That said, I wanted to keep my dependencies minimal, but I wanted to use protobuf for data serialization between the two.

I am not sure if this expected behavior, but importing this in my app.d does not work. I get an error about a missing import. I ran to my 'root' where my dub.sdl was, ran the build for the library which worked, but when I went back to my file, I get the same behavior. I am not sure what to make of this. I figured the library was out of date, but I didn't think much of it. I am actually not sure what to do since package managers are kind of voodoo magic to me.

To start, I am on Arch Linux and using the most recent D. Here is my dub.sdl. If this continues to give me issues, I might use a different library or serialization method...

name "protostate"
description "A minimal D application."
authors "Nicol Farran Terra"
copyright "Copyright © 2024, Nicol Farran Terra"
license "MIT"
dependency "protobuf" version="~>0.6.2"

I think this is expected behavior my first intuition is simply that 'this does not conform with modern D' or 'it is not found and I cannot install a package with dub'.
Both seem plausible to me. Any help would be appreciated.

On Saturday, 24 August 2024 at 00:24:12 UTC, Nicol Farran Terra wrote:

You are importing google.protobuf, right?
Providing the app.d would be helpful, or at least a snippet of it with the import that’s giving you the ‘error’—presumably a compiler error?

Could you please elaborate about what this means? It’s a bit confusing.

On Saturday, 24 August 2024 at 06:35:50 UTC, IchorDev wrote:

No, I am just importing 'protobuf'. Also the app is literally the base app when you run dub.init.
Here is a more exact error.
app.d(2): Error: unable to read module protobuf
app.d(2): Expected 'google/protobuf.d' or 'google/protobuf/package.d' in one of the following import paths:
import path[0] = /usr/include/dlang/dmd

Also, I tried with both google.protobuf and just protobuf. Same error. Although I do remember I got something interesting when trying to build a subproject of this one (it wasnt there for some reason)
Uhh, just 'root'. Where my dub.sdl is?
It is not overall project root, that is where my Package.swift files. It is in my Sources/source (yes because Dub does that by default + app.d) and in Sources is where my dub.sdl.
If you go to where my folder location is, and run dub build. It 'works' fine if you run 'dub build'. Although only if you just import anything in std. If you try to import protobuf in the app.d, it just wont work. Here is that error.
source/app.d(2,8): Error: unable to read module protobuf
source/app.d(2,8): Expected 'protobuf.d' or 'protobuf/package.d' in one of the following import paths:
import path[0] = source/
import path[1] = ../../../../.dub/packages/protobuf/0.6.2/protobuf/src/
import path[2] = /usr/include/dlang/dmd
Error /usr/bin/dmd failed with exit code 1.

On Saturday, 24 August 2024 at 11:34:18 UTC, Nicol Farran Terra wrote:

Well, the package path is google.protobuf. If you import protobuf then you are telling the compiler to import something that does not exist, so naturally that gives you this error:

So, how does this error look when you import google.protobuf?

dub is telling you the file path:
../../../../.dub/packages/protobuf/0.6.2/protobuf/src/ ~ (protobuf.d or protobuf/package.d).
If you look, you will see that there’s no such file or folder, but there should be a google folder & a protobuf folder inside it. The folder structure defines how the modules & packages are named (i.e. google/protobuf/package.d => import google.protobuf), so in the future you can check the folder structure if you have this issue anywhere else, since sometimes dub packages just don’t say how they should be imported.

Are you just running dmd on app.d from inside source this time? If not then why are all of your project’s import paths missing??

Did you try dub build protobuf:protoc-gen-d?

Yes, that’s the root directory of your dub package.

On Saturday, 24 August 2024 at 12:11:03 UTC, IchorDev wrote:

Okay, yeah now I see my problem sort of. So now it at least builds, but it wont compile with dmd app.d.
Says basically the same thing before where it cannot find the module. Maybe I am supposed to link it? I am so used to doing single file projects, I just did dmd app.d to see if it would work.

But yes, good news is in dub.sdl root, it builds. So I think I am good? Maybe I am just missing something in the compiler use lol. I think I can assume if I can build with my SDL at my dub.sdl root, it should be fine. I think. Idk

On Saturday, 24 August 2024 at 12:24:04 UTC, Nicol Farran Terra wrote:

If you build directly with dmd you will have to specify everything you build against manually, including your dependencies’ import directories. However, there’s no reason to do that since dub does this for you (and caches builds too). If you want to know what commands dub is running to build your project then you can use dub -v --force.

On Saturday, 24 August 2024 at 12:29:41 UTC, IchorDev wrote:

That is....very helpful. So sort of like Swift, running the 'build' command will just go through my source tree and just make sure everything links + builds for compile or am I missing something?
So basically, unless I want to use the compiler -f flag, I should probably just use dub build going forward to see if my work compiles.

On Saturday, 24 August 2024 at 12:35:03 UTC, Nicol Farran Terra wrote:

You’re spot on.

You could add dflags "-f" to your dub.sdl if you want the compiler to be passed -f: https://dub.pm/dub-reference/build_settings/#dflags
Keep in mind that some flags are compiler-specific, so if you want to try LDC2 or GDC you might need to create compiler-specific variations:

dflags "-example" platform="dmd"
dflags "-example" platform="ldc"
dflags "--example" platform="gdc"

Good luck!

On Saturday, 24 August 2024 at 00:24:12 UTC, Nicol Farran Terra wrote:

Maybe consider to use msgpack instead of protobuf

This version of protobuf is broken for modern versions of D compilers