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
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
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
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
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
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
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
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
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
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