Great! Thanks!

Been away for a while, time to upgrade...

I think I mention this at least once a year, but Microsoft SDK conventions are an ever increasing clusterfuck...

And weirdly enough, the removal of:

Vector<Ln>       line; 

from TextCtrl is affecting me.

That is fixable, I just need to update and merge for inherited controls.

The BM detection needs to be fixed though.

I'm willing to boot up a few VMs and test a few clean setups.

Any help with that is highly appreciated.

There is nothing magical about the detection, check "ide/InstantSetup.cpp".

Unfotunately, it appears to be really fragile. ("it works on my machine"). I actually think that things got broken when I was "forced" by the community to replace dump "search through all directories" approach to using registry entries to "make it fast". (check svn history)

Maybe it is the time to get back to dumb.

Mirek

bool BuildMethod::TestLib(bool px86, bool px64) {
	if (Compiler.IsEmpty() || Sdk.IsEmpty())
		return false;
	
	if (px86) {
		Vector<String> x86um;
		Vector<String> x86ucrt;
		
		if (FindFile(Sdk + "\\lib\\*.lib"))
			x86um.Add("\\lib\\");
		else if (FindFile(Sdk + "\\lib\\x86\\*.lib"))
			x86um.Add("\\lib\\x86\\");
		else if (FindFile(Sdk + "\\lib\\win8\\um\\x86\\*.lib"))
			x86um.Add("\\lib\\win8\\um\\x86\\");
		else if (FindFile(Sdk + "\\lib\\winv6.3\\um\\x86"))
			x86um.Add("\\lib\\winv6.3\\um\\x86\\");
		else {
			FindFile ff(Sdk + "\\lib\\*");
			while (ff) {
				
				if (ff.IsDirectory()) {
					String s = ff.GetName();
					if (s != ".." && s != ".") {
						String p = ff.GetPath();
						if (FileExists(p + "\\um\\x86\\User32.Lib")) {
							x86um.Add("\\lib\\" + ff.GetName() + "\\um\\x86\\");
							//break;
						}
						if (FileExists(p + "\\ucrt\\x86\\*.lib"))
							x86ucrt.Add("\\lib\\" + ff.GetName() + "\\ucrt\\x86\\");
					}
				}
				ff.Next();
			}
		}
		
		if (x86um.GetCount() == 0)
			return false;
		for (int i = x86um.GetCount() - 1; i >= 0; i--) {
			Lib32 << Sdk + x86um[i];
		}
		for (int i = x86ucrt.GetCount() - 1; i >= 0; i--) {
			Lib32 << Sdk + x86ucrt[i];
		}
		if (FileExists(Compiler + "\\VC\\lib\\*.lib"))
			Lib32 << Compiler + "\\VC\\lib\\";
	}

Linking...
LINK : c:\z2c\eye.exe not found or not built by the last incremental link; performing full link
c:\z2c\eye.exe  ( B) linked in (0:01.23)

So I'm preparing a VM right now with a 100% legal Windows 10.

Could you please provide some semblance of what the installation steps should be. There used to be some instructions on the site but right now I can't find them. Probably because auto-detection doesn't work.

Then I will replicate the steps and show auto-detection results.

Two first choices should be VS 2015 and VS 2017 community edition, right?

bin = df.Get(x64 ? "/windows kits/10/bin/10.0.16299.0/x86" : "windows kits/10/bin/10.0.16299.0/x86", "makecat.exe;accevent.exe");

Linking...
LINK : c:\z2c\zide.exe not found or not built by the last incremental link; performing full link
   Creating library c:\z2c\zide.lib and object c:\z2c\zide.exp
c:\z2c\zide.exe  ( B) linked in (0:01.64)

No reason to bother with VS2015

It looks like the problem with VS2015 is that in the SDK folder, some files are not in the x86 subfolder, but in 10.0.16299.0/x86.

Do we need those binaries too? Are the VC ones + includes + libs not enough?

bin = df.Get(x64 ? "/windows kits/10/bin/10.0.16299.0/x86" : "windows kits/10/bin/10.0.16299.0/x86", "makecat.exe;accevent.exe");

This fixes both VS 2017 and VS 2015.

A real fix will be needed that looks in all the subfolders, not just 10.0.16299.0.

But first the question is: is it my install or the fact that I added VS2017 on top of 2015. I'll test in the VM that only has 2017 and on one with only VS2015 and get back to you with the results.

I guess it is MS constantly changing everything...

mirek wrote on Wed, 10 January 2018 12:29

I guess it is MS constantly changing everything...

I guess MS were as short sighted as usual and did not anticipate several versions of the same SDK (all 10). This time they didn't go with 7 vs 7a or 8 and 8.1 scheme.

Anyway, 2017 does indeed use versioning. Tested on the clean VM. I'll try to fix it as with the libs and test it for a while and provide the fix.

Sorry this is taking a while, but my clean VM PC is the opposite corner of the city from my work PCs where I have every single VS version in existence.

So fast!

I'll check!

Do you have idea on the other problem I mentioned? I can't debug even command line apps with "target file override".