How to setup D with SFML? (using bindbc-sfml)

[Mike Parker]

On Sunday, 9 April 2023 at 09:54:26 UTC, Ki Rill wrote:

>
> Why can't it find these libraries? I tell where to look for 
> them:
> ```D
> version(Windows) {
>     import bindbc.loader;
>     setCustomLoaderSearchPath("libs"); // tried using absolute 
> path as well
> }
> ```
>
> That is strange...

I've tried your project out two ways, one that succeeds and one 
that fails. I'm guessing you've put your 'libs' directory is 
'bin/libs'. Am I right? If so, then the following should help you.

When dub runs the exectuable, it sets the current working 
directory to the project's root directory by default. 
`setCustomLoaderPath` passes whatever you give it directly to the 
system API unmodified. You've passed a relative path. By default, 
the system API associates relative paths with the current working 
directory.

So given a project root directory of `$ROOT`, and your executable 
in `$ROOT/bin`, the system is looking for the libraries in 
`$ROOT/libs` and *not* in `$ROOT/bin/libs`. If the libs are in 
the former, everything loads. If they're in the latter, then it's 
going to fail.

If you cd into `bin` and run the executable manually, then libs 
in `$ROOT/bin/libs` will load, as your current working directory 
is `bin`.

The quick fix for this is to add `"workingDirectory" : "bin"` to 
your dub.json. Then your relative paths will be relative to 
`$ROOT/bin/`.

Bear in mind that when using relative paths like this, any file 
reading is bound to break if someone runs your executable from 
outside its directory. You can test this by going into `$ROOT` 
from the command line and executing 
`bin/d-sfml-project-template`. Then you'll be doing the same 
thing dub does, i.e., your working directory will be `$ROOT`.

The way to guarantee your relative paths are always relative to 
the executable are to either set the current working directory to 
the executable's path, or to prepend all relative paths with the 
executable's path before handing them off to the system.

There are two ways you can get the full path to the executable in 
Phobos/DRuntime: via `std.file.thisExePath`, or 
`core.runtime.Runtime.args[0]`. (The former is failing to compile 
for me on Windows right now due to a bug in the Phobos Win32 API 
bindings. I'll look into it.)

Strip the file name from the returned path, then you can use it 
as required.