Dmd sc.ini and VS do not work well together!

[Igor via Digitalmars-d]

On Sunday, 24 January 2016 at 05:34:18 UTC, Brad Anderson wrote:
> On Saturday, 23 January 2016 at 21:38:19 UTC, Igor wrote:
>> I feel like I am in the cave man times.  I installed Dmd2 from 
>> scratch. VisualD x64 project would not compile due to 
>> libucrt.lib not being found.
>
> Sorry you are having trouble. The Universal CRT and Visual 
> Studio 2015 are very new and I'm sure there are still some bugs 
> to work out.
>

Ok, I hope that it will be fixed because it seems like a rather 
simple issue(location issue). I can't know if there are any other 
problems until it is fixed.


>> [snip]
>>
> HKLM "Software\Microsoft\Windows Kits\Installed Roots" 
> "KitsRoot10"
>
> Then searching for the latest UCRT version in a subdirectory. 
> That's probably where the bug is. This is brand new detection 
> however so it might be buggy.
>
> You can see how it works here: 
> https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L379
>
> Would you happen to know a better way to do this?
>
>> [snip]
>>
>> The installer should be modernized and provide path 
>> information and resolve dependencies properly before 
>> installing. It is clear that dmd was not designed for windows 
>> use.
>
> We make updates to it pretty much every release cycle. We'd 
> love some help making it bulletproof. Rock solid VS/Platform 
> SDK detection is what we want but it's proved a bit trickier 
> than expected (Microsoft has changed a few things up with 
> different VS releases so there is not just one way to do it).


Ok, I think you need to use all the reg keys in

HKLM "Software\Microsoft\Windows Kits\Installed Roots"

and search all valid paths for the proper files. In my case, if 
that was done, it would find the proper library files.

Basically any subdirectory that has a lib file is a possible 
candidate for a lib path. This is the part!

The hard part is to figure out which are the "correct" libs. One 
can check the libs for architecture. 32-bit libs folders are 
candidates for the 32-bit build and ditto for 64-bit.

Out of those, one should determine debug versions and separate 
that, even though sc.ini doesn't seem to have this capability. 
Maybe it could be added and then dmd can choose the correct path 
for debug builds.

After than, one will have duplicates due to versioning. One could 
try and partition down further, take the latest version, or 
present the user with options at this point.

At the very least, the installer could add all possible path 
candidates to the sc.ini as comments so when one goes in and 
edits the file, they just have to try one at a time and not go 
bonkers looking for the paths. Also, allow the option to copy the 
lib files(and possibly VC linker files) into a subfolder to use 
instead. This way one can avoid even having to reinstall the kits 
or could uninstall them and still retain the libraries outside of 
the VS mess. This would avoid having to have multiple VS versions 
installed.

A simple sc.ini reconfiguration tool or re-install/modify could 
then be used to select the different build varieties.