Issue with sc.ini within XMake build infrastructure

[Andre Pany]

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é