LLVM Drops Windows XP Support; Work Continues On CMake To Replace Autoconf

[phoronix]

Phoronix: LLVM Drops Windows XP Support; Work Continues On CMake To Replace Autoconf

Quick note for anyone who has a vested interest in LLVM/Clang on Windows or in Windows XP: LLVM has ended its support...

http://www.phoronix.com/scan.php?pag...ops-Windows-XP

[cb88]

Note that it will still be able to target XP but not run on it. Other wise Mozilla would be up the creek with thier intentions to have Servo run on XP as a minimum.

[mark45]

Although WinXP has 10% market share, it's not worth supporting it unless you got a client asking for it worth the effort.
Though, for the Ministry of Defense WinXP is probably too new of an OS, up until recently their nuclear gear was running on a MSDOS-era OS carrying data on big floppy disks..

[cb88]

Although WinXP has 10% market share, it's not worth supporting it unless you got a client asking for it worth the effort.
Though, for the Ministry of Defense WinXP is probably too new of an OS, up until recently their nuclear gear was running on a MSDOS-era OS carrying data on big floppy disks..

And that is probably a good idea ... if it ain't broke don't fix it. You could train a guy to understand just about all of MS-DOS *and* the hardware for less than 100k and keep him on payroll for 70kish depending on the area. You'd need a TEAM to do anything newer... not to mention new development costs for basically no reason. Though you can't buy new 8086s that I know of you can still buy 6502s for example... sometimes upgrading is THE STUPIDEST thing you can do... and seriously if they upgraded to Windows would you want those guys playing reversi!!!?

[Passso]

While I was working in a bank a few years ago there was a data machine for financial tasks dating from 1970...

The fact is I never had to mind it or reboot it, we just payed a contract so that if it had issues a new one was sent directly from the 70s

Factories still have a load of WinXP, so I think it has FAR MORE than 10% market, mostly hidden (ie not accessing to Internet).
Most of its use are embedded systems, cash register, controllers etc.

[gamerk2]

While I was working in a bank a few years ago there was a data machine for financial tasks dating from 1970...

The fact is I never had to mind it or reboot it, we just payed a contract so that if it had issues a new one was sent directly from the 70s

Factories still have a load of WinXP, so I think it has FAR MORE than 10% market, mostly hidden (ie not accessing to Internet).
Most of its use are embedded systems, cash register, controllers etc.

Pretty much this; I still have to support a Windows 3.11 PC and a VAX/VMS server.

[SystemCrasher]

I wouldn't recommend cmake to anyone. Autoconf isn't very great for dev's, but on other hand it is a real maintainer's and builder's friend. Cmake on other hand is just a PITA. Crappy diagnostic messages, or to be exact, lack of them in most cases. Very bad logging. Strange and bugged detection of libs, etc. Completely wrecked screen output on something like make -j 8 (are these nuts still building on single CPU core?) where various jobs race for screen output and their fancy progress indication turns into horribly broken spam instead. Various caches states all across your drive - try to guess why it so persistent on failing your build, even after problem corrected. It caches some internal states and it makes (re)configuring really painful, especially if build fails due to bad lib detection, etc. All this is a hallmark of cmake, as seen when trying to build dozens of various programs.

Recently I attempted to build yet another program which both supports autoconf and cmake under Linux. First I gave a try cmake to see if it improved (it had a bit less dependencies than autoconf, either, which is a good thing). Nope, it's still same crapwreck as years ago! Build just silently failed for ... uhm, "some reason". And drilling it down was quite a tiresome and came to missnig lib (no, there was no message about missing lib, in human readable form). And it takes a lot of efforts to get idea what failed - cmake detection facilities and logging probably were coded by aliens. On other hand, once I ran configure generated by autoconf, it would at least fail properly and would write WHICH lib it needs. Saving me a lot of time on digging somewhere in internals. So, at least, autoconf works, unlike cmake. Even if it got crappy internals.