www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is DUB not passing dll.def file to linker

reply Igor <stojkovic.igor gmail.com> writes:
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-C56D6B49201C03F44B01E7546
8EACEE\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-C56D6B49201C03F44B01E7546
8EACEE\handmade.dll .dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E7546
8EACEE\handmade.obj -m64 -shared -g
Copying target from 
D:\git\temp\.dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E7546
8EACEE\handmade.dll to D:\git\temp\build

There is no mention of dll.def file.
May 20 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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
May 20 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
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-C56D6B49201C03F44B01E7546
8EACEE\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-C56D6B49201C03F44B01E7546
8EACEE\handmade.dll .dub\build\internal-debug-windows-x86_64-dmd_2074-C56D6B49201C03F44B01E7546
8EACEE\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?
May 20 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 20 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
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?
May 21 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 21 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
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.
May 21 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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
May 21 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 21 2017
parent Igor <stojkovic.igor gmail.com> writes:
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"],
May 21 2017