www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12443] New: Allow passing DLLs directly to DMD to avoid the need for creating import libraries

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12443

           Summary: Allow passing DLLs directly to DMD to avoid the need
                    for creating import libraries
           Product: D
           Version: D2
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-23
03:10:12 PDT ---
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.

-- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 23 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12443


Vladimir Panteleev <thecybershadow gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow gmail.com


--- Comment #1 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-23
12:13:43 EET ---
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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 23 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12443



--- Comment #2 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-23
03:24:26 PDT ---
(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.. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 23 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12443



--- Comment #3 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-23
03:42:05 PDT ---
(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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 23 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12443



--- Comment #4 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-23
12:44:20 EET ---
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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 23 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12443



--- Comment #5 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-23
03:47:16 PDT ---
(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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 23 2014