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".

cbpporter wrote on Thu, 11 January 2018 09:46

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".

Unable to reproduce (so far). "works on my machine"

Any further input on this is appreciated.

For now I had to revert versions.

I tried 2017.1 and it works, but it is way too ancient. It misses several fixes I need, 2 of them done by me. So I can't use it.

I am now on the 2017.2 RC, it has all the fixes I need and it works I think. Need to test more.

So from RC to release the debugging + target override got broken.

Narrowing it down further...

My tests were with a self-compiled TheIDE, but I was using a 64bit to debug 32, like I usually do. Updating to nightly didn't help.

But I figured that my upp folder was compromised and indeed, after a fresh install, it works. As an added bonus BLITZ works again. It didn't on my broken setup. Autodection works too, at least for 2017.

So everything is a go. Thank you!

Which reminds me: it is probably time to stop using 32 bit for good.

How do you manage both 32 and 64 bit binary releases? Not for U++, but in general. Two packages? One package with both 32 bit and 64 binaries, with different names? Is there some lightweight .bat or .exe or something to autodetect and launch the proper version?

But I figured that my upp folder was compromised and indeed, after a fresh install, it works. As an added bonus BLITZ works again. It didn't on my broken setup. Autodection works too, at least for 2017.

(Asking because thinking about doing the next release soon)

cbpporter wrote on Mon, 15 January 2018 10:37

But I figured that my upp folder was compromised and indeed, after a fresh install, it works. As an added bonus BLITZ works again. It didn't on my broken setup. Autodection works too, at least for 2017.

OK, so nightly build install now works out of box? (Asking because thinking about doing the next release soon).

Mirek