www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Issue with sc.ini within XMake build infrastructure

reply Andre Pany <andre s-e-a-p.de> writes:
Hi,

I have a windows slave on which the dmd archive is extracted and 
dub is executed using build scripts. The windows slave has Visual 
Studio 2017 installed.

I would like to switch from OMF to COFF executables to also allow 
64 bit compilations.
My issue is, there is no way to install DMD using the executable 
setup but only extracting the DMD archive. Also editing the 
sc.ini (by a build script) I dislike.

I tried to begin with an easy example. I set the environment 
variables:

SET UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10
SET UCRTVersion=10.0.16299.0
SET VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.11.25503

SET LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe
SET LIB=%LIB%;"%VCINSTALLDIR%\lib\x64"
SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64"
SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"

and after that I called dmd to compile a test application using 
the -m64 switch.
 From the error I can see, that my LINKCMD environment variable is 
overwritten by the sc.ini line:
LINKCMD=%VCINSTALLDIR%\bin\link.exe

Error: can't run 'C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\link.exe', 
check PATH.

How can I solve this issue?

Kind regards
André
Nov 02 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/11/2017 12:42 PM, Andre Pany wrote:

 Hi,
 
 I have a windows slave on which the dmd archive is extracted and dub is 
 executed using build scripts. The windows slave has Visual Studio 2017 
 installed.
 
 I would like to switch from OMF to COFF executables to also allow 64 bit 
 compilations.
 My issue is, there is no way to install DMD using the executable setup 
 but only extracting the DMD archive. Also editing the sc.ini (by a build 
 script) I dislike.
 
 I tried to begin with an easy example. I set the environment variables:
 
 SET UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10
 SET UCRTVersion=10.0.16299.0
 SET VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
 Studio\2017\Community\VC\Tools\MSVC\14.11.25503
 
 SET LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe
 SET LIB=%LIB%;"%VCINSTALLDIR%\lib\x64"
 SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64"
 SET LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
 
 and after that I called dmd to compile a test application using the -m64 
 switch.
  From the error I can see, that my LINKCMD environment variable is 
 overwritten by the sc.ini line:
 LINKCMD=%VCINSTALLDIR%\bin\link.exe
 
 Error: can't run 'C:\Program Files (x86)\Microsoft Visual 
 Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\link.exe', check PATH.
 
 How can I solve this issue?
 
 Kind regards
 André


Override the shipped sc.ini file with your own. Simple and effective 
solution.
Nov 02 2017
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 2 November 2017 at 12:21:50 UTC, rikki cattermole 
wrote:

 Override the shipped sc.ini file with your own. Simple and 
 effective solution.


What I just found out, by calling the batch file "vcvars64.bat" 
from the visual studio folder it seems everything is already pre 
configured (LIB environment variable needed for the linker 
contains paths to lib\x64,  ucrt\x64 and um\x64) and also the 
path environment variable has already the right value in first 
place:

Path=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64;

I have to ship an almost empty sc.ini. Everything else is set by 
the vcvars64.bat file.

It would be great if the default sc.ini would anticipate the 
usage of vcvars*.bat.
Just call the batch and everything works out of the box.

Kind regards
André
Nov 02 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/11/2017 1:56 PM, Andre Pany wrote:

 On Thursday, 2 November 2017 at 12:21:50 UTC, rikki cattermole wrote:

 Override the shipped sc.ini file with your own. Simple and effective 
 solution.


 
 What I just found out, by calling the batch file "vcvars64.bat" from the 
 visual studio folder it seems everything is already pre configured (LIB 
 environment variable needed for the linker contains paths to lib\x64,  
 ucrt\x64 and um\x64) and also the path environment variable has already 
 the right value in first place:
 
 Path=C:\Program Files (x86)\Microsoft Visual 
 Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64;
 
 I have to ship an almost empty sc.ini. Everything else is set by the 
 vcvars64.bat file.
 
 It would be great if the default sc.ini would anticipate the usage of 
 vcvars*.bat.
 Just call the batch and everything works out of the box.
 
 Kind regards
 André


Guess what all "just works" with the installer? :p
Nov 02 2017
parent Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 2 November 2017 at 13:01:05 UTC, rikki cattermole 
wrote:

 On 02/11/2017 1:56 PM, Andre Pany wrote:

 On Thursday, 2 November 2017 at 12:21:50 UTC, rikki cattermole 
 wrote:

 Override the shipped sc.ini file with your own. Simple and 
 effective solution.


 
 What I just found out, by calling the batch file 
 "vcvars64.bat" from the visual studio folder it seems 
 everything is already pre configured (LIB environment variable 
 needed for the linker contains paths to lib\x64,  ucrt\x64 and 
 um\x64) and also the path environment variable has already the 
 right value in first place:
 
 Path=C:\Program Files (x86)\Microsoft Visual 
 Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64;
 
 I have to ship an almost empty sc.ini. Everything else is set 
 by the vcvars64.bat file.
 
 It would be great if the default sc.ini would anticipate the 
 usage of vcvars*.bat.
 Just call the batch and everything works out of the box.
 
 Kind regards
 André


 Guess what all "just works" with the installer? :p


unfortunately I cannot use the installer. But I found an 
interesting comment in sc.ini:
; Add the library subdirectories of all VC and Windows SDK 
versions so things
; just work for users using dmd from the VS 64-bit Command Prompt

According to these comment I would assume, after calling 
"vcvars64.bat" everything should work. Maybe it worked in the 
past and it is a bug.

My tests:
- I changed the line "LINKCMD=%VCINSTALLDIR%\bin\link.exe" to 
"LINKCMD=link.exe"
Unfortunately this optlink linker is also called link.exe *argh*

- After renaming the optlink linker to optlink.exe the microsoft 
linker does not find a lib, which is definitely in the LIB 
environment path.

I think there are some bugs to solve but it definitely makes the 
usage of Visual Studio linker much more comfortable in build 
infrastructure.

I will create an issue for this.

Kind regards
André
Nov 02 2017