On Friday, 3 November 2017 at 11:52:10 UTC, Andre Pany wrote:
Hi,
Visual Studio has a batch file which sets all needed
environment variables for the Microsoft linker (LIB environment
variables points to all necessary folders). Even the folder
containing the link.exe for the specified architecture (x86,
amd64) is added to the path variable as first path.
vsdevcmd -arch=amd64
As the sc.ini targets the windows development (visuals studio)
after calling the developer command prompt, dmd should be able
to compile -m32mscoff, -m64 out of the box without the need to
change anything within sc.ini.
There is even a comment in sc.ini which points in this
direction:
; Add the library subdirectories of all VC and Windows SDK
versions so things
; just work for users using dmd from the VS Command Prompt
Unfortunately it does not work for various reasons:
- optlink has the filename link.exe which conflicts with the
filename of the microsoft linker
- from my investigation I have the assumption that even if an
environment variable LIB exists, the value is discarded by the
sc.ini logic. I tried hard, but it seems existing environment
variable LIB cannot be used in sc.ini
If you can use the windows installer, it will set the right
values in sc.ini. But there are scenarios in which you cannot
use the windows installer but have to use the dmd zip archive
(build infrastructure scripts).
In my scenario it seems the only possibility is to adapt my
build infrastructure scripts to:
- extract dmd archive
- delete link.exe (optlink)
- modify the sc.ini
That is a solution for my case, but my gut feeling is, it
should be solved in general
to ease the usage of the microsoft linker.
I thought it was planned to rename the optlink link.exe to
optlink.exe?
Kind regards
André
I have an idea which solves several problems.
Current state:
The dmd windows archive has a folder "bin" with a 32 bit dmd
compiler which is able to create x86 and x86_64 applications. By
default the dmd compiler creates 32 bit applications using the
optlink link.exe contained also in this folder.
Idea:
Within the folder "bin64" the 64 bit dmd compiler could be
shipped within the dmd windows archive. I assume the 64 bit dmd
compiler is able to create x86 and x86_64 applications. In folder
"bin64" no optlink link.exe should be available.
The usage of either the microsoft link.exe or another linker
(maybe the one from LDC) is anticipated. The 64 bit dmd compiler
could have the option -m64 set as default.
The user can decide whether he wants to use the "stable" dmd
compiler with usage of optlink or he want to use the 64 bit dmd
compiler which is open for other linkers than optlink by simply
setting his path variable to bin or to bin64.
Using this approach:
- DMD compiler is working out of the box for the VS Developer
Command Prompt - no need to rename the optlink link.exe
- A 64 bit dmd compiler is shipped which solves issues on large D
projects
What do you think?
Kind regards
André
