I am using DUB 1.3.0. My folder structure is:
project
  dub.json
  source
    windll.d
    handmade.d
    dll.def

dub.json looks like this:

{
	"name": "handmade",
	"targetType": "dynamicLibrary",
	"targetPath": "build",
	"configurations": [
		{
			"name": "internal",
			"versions": ["HANDMADE_INTERNAL"]
		}
	]
}

But when I run: dub -v build -ax86_64 --force
I get:

Generating using build
Generate target handmade (dynamicLibrary D:\git\temp\build handmade)
Performing "debug" build using dmd for x86_64.
handmade ~master: building configuration "internal"...
dmd -m64 -c -of.dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E754688EACEE\handmade.obj -debug -g -w -version=HANDMADE_INTERNAL -version=Have_handmade -Isource source\handmade.d source\windll.d -vcolumns
Linking...
dmd -of.dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E754688EACEE\handmade.dll .dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E754688EACEE\handmade.obj -m64 -shared -g
Copying target from D:\git\temp\.dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E754688EACEE\handmade.dll to D:\git\temp\build

There is no mention of dll.def file.

On Saturday, 20 May 2017 at 19:53:16 UTC, Igor wrote:
>
> There is no mention of dll.def file.

Add a "sourceFiles" directive:

"sourceFiles-windows" : ["dll.def"]

See the comments at the following:

https://github.com/dlang/dub/issues/575
https://github.com/dlang/dub/pull/399

On Saturday, 20 May 2017 at 20:04:27 UTC, Mike Parker wrote:
> On Saturday, 20 May 2017 at 19:53:16 UTC, Igor wrote:
>>
>> There is no mention of dll.def file.
>
> Add a "sourceFiles" directive:
>
> "sourceFiles-windows" : ["dll.def"]
>
> See the comments at the following:
>
> https://github.com/dlang/dub/issues/575
> https://github.com/dlang/dub/pull/399

Thanks Mike. Google wasn't this helpful :). In the meantime I tried debugging dub to see what is happening and with this simple change in packagerecipe.d it seems to work:

    // collect source files (instead of just "*.d" i put the following at line 206)
    dst.addSourceFiles(collectFiles(sourcePaths, "*.{d,def}"));

This is the output I got:

Performing "debug" build using dmd for x86_64.
handmade ~master: building configuration "internal"...
FILES IN BUILDSETTINGS: ["dll.def", "handmade.d", "handmade_h.d", "windll.d"]
dmd -m64 -c -of.dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E754688EACEE\handmade.obj -debug -g -w -version=HANDMADE_INTERNAL -version=Have_handmade handmade.d handmade_h.d windll.d -vcolumns
Linking...
dmd -of.dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E754688EACEE\handmade.dll .dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E754688EACEE\handmade.obj dll.def -m64 -shared -g

As you can see def file just got added to link command.

So my question is if the fix is so simple what are the reasons it isn't implemented? Am I missing something?

On Saturday, 20 May 2017 at 20:26:29 UTC, Igor wrote:

> So my question is if the fix is so simple what are the reasons it isn't implemented? Am I missing something?

I don't know, but you could always submit a PR or an enhancement request.

On Saturday, 20 May 2017 at 21:36:42 UTC, Mike Parker wrote:
> On Saturday, 20 May 2017 at 20:26:29 UTC, Igor wrote:
>
>> So my question is if the fix is so simple what are the reasons it isn't implemented? Am I missing something?
>
> I don't know, but you could always submit a PR or an enhancement request.

Actually, it turned out since 32bit def file needs additional settings in it compared to 64bit version it is handy to be able to have separate def files and use:

"sourceFiles-windows-x86_64" : ["dll64.def"],
"sourceFiles-windows-x86" : ["dll32.def"],

to only pass appropriate one.

Now since dll project can't be built as a dependency I added this to my main project dub.json:

"preBuildCommands": ["cd game & dub build"],

If I now run dub build in main project both projects compile and work together, but if I run dub build -ax86_64 only main project is built as 64bit while dll project is still being built as 32bit. Does anyone have a suggestion how can I make this work for both architectures?

On Sunday, 21 May 2017 at 09:37:56 UTC, Igor wrote:

> If I now run dub build in main project both projects compile and work together, but if I run dub build -ax86_64 only main project is built as 64bit while dll project is still being built as 32bit. Does anyone have a suggestion how can I make this work for both architectures?

You'll need to pass -ax86_64 in your preBuildCommands. You could set up separate configurations.

What's the issue with using the DLL project as a dependency? Assuming the following layout:

-project
-- dllProject
-- exeProject

You should be able to add a copyFiles directive to the dllProject configuration that will copy the DLL to the output directory of anything that depends on it.

"copyFiles" : ["dllProject.dll"]

Then you can add the following to exeProject/dub.json:

"dependencies": {
    "dllProjectName": {"path" : "../dllProject" }
}

I would expect the import lib to be linked automatically. This should ensure the dll is compiled with the same architecture as the exe.

On Sunday, 21 May 2017 at 10:15:40 UTC, Mike Parker wrote:
> Then you can add the following to exeProject/dub.json:
>
> "dependencies": {
>     "dllProjectName": {"path" : "../dllProject" }
> }
>
> I would expect the import lib to be linked automatically. This should ensure the dll is compiled with the same architecture as the exe.

DUB reports:

Dynamic libraries are not yet supported as dependencies - building as static library.

On Sunday, 21 May 2017 at 10:53:42 UTC, Igor wrote:

>
> Dynamic libraries are not yet supported as dependencies - building as static library.

I see. And I'm not surprised. DLL support on Windows (at least in DMD, not sure about LDC) is still not where it needs to be. I don't know how much has changed since Benjiman Thaut's DConf talk last year [1], but I don't recall any major announcements. I expect there aren't a whole lot of people actively developing shared libraries in D.

[1] http://dconf.org/2016/talks/thaut.html

On Sunday, 21 May 2017 at 11:42:02 UTC, Mike Parker wrote:
> On Sunday, 21 May 2017 at 10:53:42 UTC, Igor wrote:
>
>>
>> Dynamic libraries are not yet supported as dependencies - building as static library.
>
> I see. And I'm not surprised. DLL support on Windows (at least in DMD, not sure about LDC) is still not where it needs to be. I don't know how much has changed since Benjiman Thaut's DConf talk last year [1], but I don't recall any major announcements. I expect there aren't a whole lot of people actively developing shared libraries in D.
>
> [1] http://dconf.org/2016/talks/thaut.html

So what I would try in your situation is to add three new configurations to the exeProject's dub.json. Use the "platforms" directive to limit one to "windows-x86", another to "windows-x86_64", and leave the other one empty. List the empty one last and it should become the default on non-Windows platforms. Move your preBuildCommands directive to the windows-x86 configuration, and copy it to the windows-x86_64 configuration with the addition of "-ax86_64" to the "dub build" command.

On Sunday, 21 May 2017 at 11:47:15 UTC, Mike Parker wrote:
> So what I would try in your situation is to add three new configurations to the exeProject's dub.json. Use the "platforms" directive to limit one to "windows-x86", another to "windows-x86_64", and leave the other one empty. List the empty one last and it should become the default on non-Windows platforms. Move your preBuildCommands directive to the windows-x86 configuration, and copy it to the windows-x86_64 configuration with the addition of "-ax86_64" to the "dub build" command.

Thanks for the suggestion Mike. I just added this for now and it works:

    "preBuildCommands-x86_64": ["cd game & dub build -ax86_64"],
    "preBuildCommands-x86": ["cd game & dub build"],