Bug 12443 – Allow passing DLLs directly to DMD to avoid the need for creating import libraries

Comments from: https://github.com/D-Programming-Language/dmd/pull/3397#issuecomment-38364330 https://github.com/D-Programming-Language/dmd/pull/3397#issuecomment-38376746 > W.r.t. Windows, I was thinking the other day that it would be great if we could > pass DLLs to DMD directly instead of having to create an import library as a > separate step. But neither implib nor coffimplib are open-source so I don't > know how hard it would be to implement this in the compiler.

For the record, Delphi does away with import libraries completely and solves the DLL problem in the language. E.g.: function MessageBoxA(hWnd: HWND; lpText, lpCaption: PChar; uType: UINT): Integer; stdcall; external 'user32.dll'; So in theory D could have an extern(dll, "user32.dll") attribute.

(In reply to comment #1) > For the record, Delphi does away with import libraries completely and solves > the DLL problem in the language. E.g.: > > function MessageBoxA(hWnd: HWND; lpText, lpCaption: PChar; uType: UINT): > Integer; stdcall; external 'user32.dll'; > > So in theory D could have an extern(dll, "user32.dll") attribute. It would be a little complicated with platform-independent shared libraries. For example: ----- version (Windows) extern(dll, "user32.dll") extern(C) void foo(); void main() { foo(); // would fail on Posix since the entire block becomes invisible } ----- We currently cannot do the following: ----- version (Windows) extern(C++): else extern(C): void foo(); void main() { } ----- Unless this is fixed extern(dll, "user32.dll") would only be usable for Windows DLLs, or you'd likely have to duplicate code / resort to string mixins and other unreadable hacks..

(In reply to comment #2) > ----- > version (Windows) extern(dll, "user32.dll") > extern(C) void foo(); > > void main() > { > foo(); // would fail on Posix since the entire block becomes invisible > } > ----- That wasn't a proper argument since the dll string name can be generated at compile-time. To provide a slightly better argument, let's say you have "foo.dll", "foo_deb.dll" on Windows, and "foo.a", "foo_deb.a" on Posix. You'd end up writing: ----- version (Windows) { debug enum dll_name = "foo.dll"; else enum dll_name = "foo_deb"; } else version (Posix) { debug enum dll_name = "foo.a"; else enum dll_name = "foo_deb.a"; } extern(dll, dll_name) void foo(); ----- But then there might be issues where the shared library is named differently based on the OS itself, some platform-specific naming conventions, x86 vs x64, etc.. It would be simpler if you could just pass the shared library directly to DMD.

It would be simpler if the project is already using some non-trivial build system. Allowing specifying it in the source code has the same advantage as pragma(lib): it allows using only rdmd to build the program. I think there is merit in both.

(In reply to comment #4) > It would be simpler if the project is already using some non-trivial build > system. Allowing specifying it in the source code has the same advantage as > pragma(lib): it allows using only rdmd to build the program. Well, yeah, but you still can't provide strings at compile time via a compiler switch, maybe only through string imports. (In reply to comment #4) > I think there is merit in both. Yes, agreed.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18800 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB